I giorni successivi
Nel tempo trascorso dall'incontro ho avuto conversazioni con Steve Wolfe (UCLA-CCN), Bill Crowther (BBN), e John Heafner ed Erick Harslem (RAND). I commenti di Wolfe compariranno come NWG/RFC #38 e rientrano in una classe su cui commenterò più avanti.
Crowther ha presentato quanto segue:
“Breve descrizione di due idee per semplificare il protocollo host descritto all'incontro di marzo. Queste idee non sono state elaborate con cura.
Idea 1. Riconnettere.
“Un NCP che vuole riconnettersi dice a ciascuno dei suoi vicini ‘voglio riconnettermi’. Essi attendono finché non ci sono messaggi in transito e rispondono ‘OK’. Egli allora dice ‘riconnettetevi come segue’ ed essi lo fanno. Nella condizione rara, l'NCP riceve in risposta un ‘voglio riconnettermi’ invece di un ‘OK’; allora uno deve andare e uno deve fermarsi. Quindi trattate una ‘riconnessione’ da un utente Host superiore, ecc., come un ok e da uno inferiore come un ‘No — attendi finché non ti riconnetto’ ed eseguite la connessione.
Idea 2
“Disaccoppiare connessioni e collegamenti. Stabilire comunque le connessioni, ma usare un qualsiasi collegamento a portata di mano per i messaggi. Non inviare un altro messaggio su una connessione finché non ritorna un RFNM. Includere nel pacchetto i numeri di socket di origine e destinazione.
“Per riconnettere, dite a ciascuno dei vicini ‘riconnettetemi come segue...’. Mantenete la connessione per un breve tempo (secondi) e inviate sia i pacchetti sia i messaggi di connessione verso le loro destinazioni. Non ho elaborato come mantenere in ordine i messaggi in transito, ma probabilmente tutto funziona se non inviate una riconnessione mentre sono in sospeso dei RFNM.”
La prima idea di Bill non mi sembra né decisamente migliore né (dopo qualche riflessione) molto diversa, e la sto considerando. Non ho ancora sentimenti forti al riguardo, ma sto cercando di svilupparne alcuni.
La seconda idea di Bill mi sembra contraria alla mia concezione del ruolo dei collegamenti. Un argomento a favore del disaccoppiamento di connessioni e collegamenti è che il numero di connessioni tra due host potrebbe superare 255, e che anche in caso contrario sarebbe una pratica più solida isolare le dipendenze nella progettazione. D'altro canto, la funzionalità di arresto del collegamento* appena introdotta (pagina 22 del rapporto BBN #1822 di prossima pubblicazione, riveduto nel febbraio 1970) diventa inutile. (Bill, che ha appena introdotto la funzionalità, non se ne preoccupa.) Un'altra obiezione è che sembra intuitivamente sbagliato sprecare la possibilità di usare il campo di collegamento per trasportare informazioni. (Si noti il conflitto di sensazioni viscerali).
In una conversazione con John Haefner ed Eric Harslem di RAND, essi hanno fatto notare che il protocollo attuale non prevede alcuna disposizione per il rilevamento e la segnalazione degli errori, la verifica e la segnalazione dello stato, e l'espansione e la sperimentazione. Il rilevamento degli errori e la verifica dello stato richiederanno una discussione più ampia per stabilire che cosa sia utile, e mi aspetto che tale discussione avvenga mentre l'implementazione procede. Lasciare spazio per l'espansione e la sperimentazione del protocollo, tuttavia, è meglio farlo ora.
Suggerisco che vengano riservate due aree per l'espansione. Una è che venga usata solo una frazione dei 256 collegamenti, diciamo i primi 32. L'altra area è usare codici di comando a partire da 255 verso il basso, con codici permanenti assegnati dal numero di collegamenti in uso fino a 32; ritengo che sia del tutto improbabile che ci servano più di 32 per parecchio tempo e, inoltre, la rete probabilmente non gestirebbe il traffico implicato da un'assegnazione pesante di collegamenti. (Queste due cose non sono necessariamente strettamente accoppiate: si possono avere molti collegamenti assegnati ma solo pochi che trasportano traffico in un dato momento.)
Alcune altre idee di Heafner e Harslem potrebbero comparire in forma di NWG/RFC.
Interazione immediata
Nei prossimi giorni sarò ancora interessato a quelle critiche del protocollo attuale che potrebbero portare al suo rifiuto o a una sua modifica seria. In seguito, l'attenzione sarà rivolta al perfezionamento, all'implementazione, all'estensione e all'utilizzazione. Posso essere raggiunto a UCLA tramite la mia segretaria, la signora Benita Kristel, al numero (213) 825-2368. Inoltre, tutti sono invitati a contribuire alla serie NWG/RFC. I numeri univoci sono assegnati da Benita.
* La funzionalità di arresto del collegamento è un modo in cui un host ricevente modifica i RFNM in modo da veicolare un significato di soppressione del flusso. Una procedura alternativa è usare un comando di controllo da host a host.
Nota: Questo RFC è stato messo in forma leggibile dalla macchina per l'inserimento negli archivi RFC online da Ron Fitzherbert 1/97.