I. Errori e overflow

In linea con la discussione in NWG/RFC #48, abbiamo ritenuto che si debbano distinguere due tipi di errori. Uno è un errore reale, come una RFC composta da due socket di invio. Questo tipo di errore può essere generato soltanto da un NCP guasto. In assenza di bug hardware e software, questi eventi non dovrebbero mai verificarsi; la risposta corretta al rilevamento di un tale evento è stata delineata nella descrizione del comando ERR in NWG/RFC #54.

L'altro "errore" è una condizione di overflow che nasce dall'esaurimento di risorse di sistema finite. Una condizione di overflow potrebbe verificarsi se una RFC venisse ricevuta ma non ci fosse spazio per creare le tabelle e le code necessarie. Non si tratta di un errore reale, nel senso che nessuno ha fatto qualcosa di scorretto (salvo forse i progettisti del sistema, per non aver previsto spazio sufficiente per le tabelle, ecc.). Inoltre è possibile definire in modo preciso una procedura di recupero, che si limita a ripetere la richiesta in un momento futuro. Riteniamo quindi che una condizione di overflow debba essere distinta da un errore reale.

In NWG/RFC #54 una condizione di overflow veniva segnalata restituendo un CLS, come se la connessione fosse stata rifiutata. Questa sequenza svolge le funzioni necessarie e lascia la connessione nello stato corretto, ma l'utente che ne prende l'iniziativa riceve un'informazione errata. Vi è indotto a credere di essere stato rifiutato dal processo remoto, quando in realtà non è così. In certi algoritmi questa differenza è cruciale.

Nel definire ulteriormente le condizioni di errore, abbiamo ritenuto utile specificare perché l'errore è stato rilevato, oltre a specificare che cosa lo ha causato. Scrivendo il programma in pseudo-Algol menzionato in NWG/RFC #55 abbiamo distinto 9 tipi di errori (elencati di seguito). Vorremmo quindi proporre di estendere il messaggio ERR includendo, dopo l'op code, un campo di 8 bit che designi il tipo di errore. A questo seguirebbero, come prima, i campi length e text. Proponiamo questi tipi di errore:

0. UNSPECIFIED ERROR
1. HOMOSEX (coppia invio/ricezione non valida in una RFC)
2. ILLEGAL OP CODE
3. ILLEGAL LEADER (tipo di messaggio errato, ecc.)
4. ILLEGAL COMMAND SEQUENCE
5. ILLEGAL SOCKET SPECIFICATION - COMMAND
6. ILLEGAL COMMAND LENGTH (l'ultimo comando del messaggio era troppo corto)
7. CONNECTION NOT OPEN - DATA
8. DATA OVERFLOW (messaggio più lungo dello spazio di buffer disponibile dichiarato)
9. ILLEGAL SOCKET SPECIFICATION - DATA (il socket non esiste)

Alla luce delle altre considerazioni menzionate sopra, vorremmo anche proporre un ulteriore comando di controllo per indicare l'overflow:

        +-------------+-------------------+---------------------+
        |     OVF     |     my socket     |     your socket     |
        +-------------+-------------------+---------------------+

Il formato dei messaggi è simile a quello del messaggio CLS, che esso sostituisce in questo contesto. I numeri di socket sono lunghi 32 bit e corrispondono ai numeri di socket nella RFC che viene rifiutata. La semantica di un OVF in arrivo dovrebbe essere identica a quella di un CLS in arrivo; in aggiunta, l'utente dovrebbe essere informato che non è stato rifiutato, ma che piuttosto ha sovraccaricato le risorse dell'host remoto.

Un'alternativa alla creazione di un comando di controllo separato può essere realizzata considerando la somiglianza tra un CLS e un OVF. Concebilmente, si potrebbe aggiungere al comando CLS un campo di otto bit per definirne la provenienza. Riteniamo tuttavia che questa alternativa sia concettualmente inferiore e praticamente più difficile da implementare.

L'overflow non richiede una seria considerazione se è un evento significativamente raro. Non crediamo che sarà così, e crediamo inoltre che la sua assenza costituirà una restrizione inutile per l'utente.