Introduzione

Il protocollo prevede uno schema di allocazione dei buffer. Tale schema è piuttosto complicato, perché richiede due meccanismi paralleli. Non è ovvio che entrambi siano necessari. In effetti, si suggerisce che tale schema potrebbe probabilmente essere sostituito da una concezione leggermente diversa della richiesta del messaggio successivo (RFNM). Ora, l'RFNM viene restituito dall'IMP ricevente dopo che il messaggio è stato ricostituito e il primo pacchetto è stato trasmesso all'host. Nulla garantisce che l'intero messaggio sia stato accettato e correttamente ricevuto dall'host; inoltre, la progettazione dell'interfaccia host/IMP consente all'host di smettere di accettare dati dall'IMP per una durata qualsiasi; poiché il collegamento è già stato sbloccato dall'invio dell'RFNM, un altro messaggio può essere trasmesso dall'host esterno mittente, il quale congestionerà la memoria dell'IMP. D'altra parte, è probabile che di norma l'host sia in grado di accettare dati dall'IMP a una velocità superiore a quella con cui vengono trasmessi sulla rete, ad esempio 200k bit/s; il tempo per trasmettere un messaggio completo dall'IMP all'host sarebbe quindi di circa 1/20 di secondo, ossia 10 volte meno del ritardo medio di trasmissione di un messaggio sulla rete. Ciò indica che inviare un RFNM dopo la ricezione di un messaggio completo da parte dell'host non aumenterebbe in modo significativo il tempo di risposta sulla rete.

In questo caso non c'è motivo per cui l'RFNM non possa essere avviato dall'host ricevente come riscontro della corretta ricezione del messaggio (ACK), assumendo la forma di un messaggio host/IMP o di un messaggio di comando di controllo. Questo RFNM potrebbe avere le due forme

         ACK  (CONTINUE)
or       ACK  (CEASE)

Ciò permetterebbe di aggiungere al messaggio una qualche ridondanza di rilevamento degli errori, come i bit di checksum proposti in [DELO 69]. Nella progettazione attuale nulla garantisce che uno o più bit del testo non siano stati alterati, ad esempio da un'interferenza o da un difetto di una delle interfacce host/IMP. Ciò potrebbe avere conseguenze importanti, ad esempio se il testo viene usato per aggiornare una base di dati centralizzata. Inoltre, se l'utente ha un modo per rilevare l'errore ma nessuno per correggerlo, non ha alcun modo di chiedere la ritrasmissione del messaggio, che probabilmente è già stato scartato all'estremità mittente al momento della ricezione dell'RFNM. In effetti, sembra che non spetti all'utente rilevare gli errori nel proprio testo, bensì all'NCP: il processo utente deve, per quanto possibile, comportarsi come se stesse parlando con un altro processo locale. Una terza specie di RFNM inviata dall'NCP potrebbe quindi essere:

            NAK(REPEAT)

La ripetizione verrebbe avviata anche in assenza di risposta.

Vediamo quindi che vale la pena apportare queste lievi modifiche, che permetterebbero di usare tra l'host mittente e l'host ricevente una procedura di trasmissione punto a punto molto semplice, in grado di garantire il controllo dei dati trasmessi da estremo a estremo.

Potrebbe inoltre sostituire il meccanismo di allocazione della memoria: ACK (CONTINUE) verrebbe inviato solo se c'è spazio per un nuovo messaggio su questa connessione e/o ACK (CEASE) verrebbe inviato se non c'è più spazio; ciò corrisponde al WABT delle procedure di trasmissione classiche [USAS69]; la trasmissione potrebbe essere ripresa da un ACK (CONTINUE) o da un RESUME proveniente dall'estremità ricevente. Il processo utente non è affatto coinvolto in questa allocazione della memoria, che è una funzione del sistema (o dell'NCP): vede solo una velocità di trasmissione globale variabile dei suoi dati su una connessione. I programmi dell'IMP si occupano dell'instradamento dei dati secondo la natura distribuita della rete, e né l'utente né il sistema (o l'NCP) se ne preoccupano. Altre migliorie al protocollo potranno essere trovate dopo averlo sperimentato.

Infine, si noti che questa soluzione non immobilizza la memoria dell'IMP più a lungo della soluzione attuale, perché non è l'IMP che deve ripetere un messaggio, ma l'host mittente.

DELO 69 DELOCHE G.  Implementation of the Host-Host Software
        Procedures in GORDO Network Working Group RFC #11 Aug 1969

USAS 69 Proposed USA standard data communication control procedures
        for USASCII CACM Vol. 12 NB 3 March 1969 PB 166-178

Nota: Questo RFC è stato reso in forma leggibile dalla macchina per l'inserimento negli archivi RFC online da Kai Henningsen 6/97.