Introduzione
Pagina 3. Eliminare la marcatura. Invece, trasformare tutti i messaggi ordinari in due messaggi: il primo contenente solo l'intestazione e indicante che i dati seguono nel secondo (successivo) messaggio. Ciò sia dall'host di origine verso il suo IMP, sia dall'IMP di destinazione verso il suo host. Così non è più necessario cercare l'inizio dei dati. Una volta apportata questa modifica, è disponibile un'ulteriore semplificazione. Se la lunghezza massima di un messaggio è un multiplo comune delle dimensioni di parola di tutti i computer della rete (forse 2880*2 bit), i messaggi successivi di un file lungo possono essere scartati sul posto senza spostamenti.
Pagina 4. I messaggi di controllo dovrebbero essere inviati verso e dal socket di controllo — non sul collegamento di controllo. Il concetto di collegamento di controllo crea un caso speciale enorme e inutile.
Pagina 5. L'assegnazione permanente di socket a determinate risorse della rete dovrebbe essere incoraggiata, e un elenco delle associazioni socket/risorsa dovrebbe essere disponibile da qualche parte nella rete, magari in forma di volume cartaceo presso ogni sito.
Pagina 6. I collegamenti non hanno altro scopo host-host che identificare una connessione, affinché i numeri di socket non debbano essere inclusi in tutti i messaggi, e semplificare le ricerche nelle tabelle degli NCP. Tuttavia, poiché possono esistere 512 collegamenti* con lo stesso numero, i collegamenti non aiutano molto le ricerche nelle tabelle. Inoltre, trovare il prossimo collegamento disponibile verso una determinata destinazione è molto brutto. Pertanto, suggerisco di limitare il numero di collegamenti a un totale di n (dove n = 32, 64 o 256 o qualche altro buon numero) per tutte le destinazioni. In altre parole, un determinato collegamento è in uso verso una sola destinazione alla volta (in realtà da una sola destinazione alla volta, poiché è il ricevente a scegliere il collegamento da usare per una connessione). Questa modifica rende la scelta del prossimo collegamento disponibile molto semplice e, ritengo, è una modifica che vale la pena, anche solo per questo motivo. La questione di semplificare le ricerche nelle tabelle è un po' più complessa. È facile usare direttamente il collegamento come indice nelle tabelle della parte di ricezione dell'NCP, poiché è il ricevente a scegliere il collegamento. Ma una tabella hash o una ricerca lineare o qualcosa del genere è ancora necessaria nella parte di trasmissione dell'NCP. Anche questo può essere risolto con le seguenti modifiche. Aggiungere a STR uno pseudo-collegamento scelto dal mittente. Questo collegamento è inviato in tutti i messaggi non di controllo, negli 8 bit a destra del collegamento nell'intestazione. L'IMP deve conservare questi bit e restituirli con gli RFNM, e il ricevente deve usare lo pseudo-collegamento invece del collegamento in RET e INR. La memoria extra necessaria per memorizzare lo pseudo-collegamento nelle tabelle di ricezione dell'NCP (indicizzate per collegamento) e il collegamento nelle tabelle di trasmissione dell'NCP (indicizzate per pseudo-collegamento) è certamente inferiore al sovraccarico necessario per mantenere tabelle associative.
*Un numero di destinazione è di 9 bit.
Pagina 8. Il meccanismo di allocazione sembra molto scomodo da usare per la parte di ricezione dell'NCP. Il ricevente vuole che l'allocazione venga consumata in unità della dimensione del buffer del ricevente, non in unità di messaggi del mittente, che possono essere di lunghezza variabile. Altrimenti il ricevente ha un problema di compattazione della memoria.
Pagina 9. I nuovi messaggi irregolari per far funzionare il meccanismo di « cease » sono inutili, credo. Il mittente può tenere traccia (probabilmente con un contatore da un bit) degli ALL e dei GVB e ignorare i GVB 0 per i quali sono già arrivati gli ALL di ripresa. Così il ricevente non ha bisogno di sapere se il cease è stato inviato o no.
Pagina 15. Se implementassi un NCP, tutti gli ERR sarebbero trattati come NOP. Come meccanismo di controllo degli errori, ERR è complicato e insufficiente. Chi vuole fare il debug di un meccanismo complicato che cattura solo i bug dovuti al fatto che il meccanismo primario non è stato sottoposto a debug. L'unico meccanismo di controllo degli errori che fornirei è un processo di ricezione che invia al processo di trasmissione un riscontro su ogni messaggio. Se questo non viene ricevuto per troppo tempo, il processo di trasmissione può rinviare il messaggio se lo ha conservato. Questo riscontro cattura gli errori che causano perdita di messaggi ai livelli processo/NCP, NCP/NCP, host/IMP, IMP/IMP, ecc. Attualmente l'interfaccia host/IMP manca in particolare di controlli di errore utili. Non mi preoccuperei dei tipi di errore che i checksum sono progettati per rilevare. Se i bit persi e ripresi male dovessero mai diventare un problema, aggiungete hardware a più interfacce oppure fate in modo che il processo di ricezione non invii il riscontro da processo a processo se un checksum software non quadra.
I commenti alle pagine 3 e 6 comportano una modifica al programma IMP. Mi sento un pochino in colpa a suggerire modifiche che non devo più implementare. Tuttavia, confido che Crowther e Cosell, come sempre, resisteranno alle modifiche cattive pur facendone di sensate. Il commento a pagina 9 mira a evitare una modifica al programma IMP.
Nota: Questo RFC è stato reso in forma leggibile dalla macchina per l'inserimento negli archivi RFC online da Luke Hollins 8/99.