I - Introduzione

In questo documento il gruppo di lavoro sulle reti del MIT Project MAC propone modifiche ed estensioni al protocollo specificato da Carr, Crocker e Cerf in una bozza del loro articolo per la SJCC del 1970 ed esteso da Crocker nell'NWG/RFC 36. Questo documento delinea in larga misura la nostra proposta ma non pretende di essere una specifica completa. Intende indicare il tipo e l'estensione del protocollo che, a nostro avviso, dovrebbe essere implementato inizialmente.

Concordiamo con il concetto di base di una comunicazione simplex tra socket aventi identificatori univoci. Proponiamo l'implementazione di un sottoinsieme leggermente modificato dei comandi di rete specificati nell'NWG/RFC36, più il comando ERR come specificato da Harslem e Heafner nell'NWG/RFC 40.

Dato l'obiettivo di base di collegare tutti gli appaltatori ARPA alla rete e di farli comunicare tra loro il prima possibile, riteniamo importante implementare un protocollo iniziale ragionevolmente semplice ma estensibile, che copra al tempo stesso i principali usi iniziali della rete. Dovrebbe essere un protocollo semplice, così da ottenere il sostegno più ampio possibile e da essere facilmente implementabile in tutte le installazioni con un minimo di software aggiuntivo.

Il protocollo si evolverà, ma i fondamenti di un protocollo accettato e implementato da tutte le installazioni si riveleranno probabilmente molto resistenti ai cambiamenti. È quindi molto importante rendere il protocollo iniziale aperto e flessibile. Un protocollo di base semplice ha maggiori probabilità di riuscirvi rispetto a uno complicato. Ciò non esclude l'esistenza di livelli di protocollo aggiuntivi tra più installazioni, purché il protocollo di base continui a essere supportato.

Riteniamo che nel protocollo iniziale debbano essere previste tre funzionalità:

1. Comunicazione a percorsi multipli tra due processi esistenti che sanno come connettersi l'uno all'altro.

2. Un modo standard perché un processo si connetta al logger (processo di accesso su un HOST) di un HOST remoto e richieda la creazione di un processo utente. (Il rituale di accesso può essere standardizzato o no.)

3. Un modo standard perché un processo appena creato avvii una comunicazione pseudo-telescrivente con il processo remoto che ne ha richiesto la creazione.

Le principali differenze tra il protocollo proposto da Carr, Crocker e Cerf e questa proposta sono le seguenti:

1. La strategia di riconnessione dinamica specificata da Crocker nell'NWG/RFC 36 è riservata a un'implementazione futura. Riteniamo che la sua inclusione complicherebbe indebitamente l'implementazione iniziale del protocollo. Delineiamo una strategia di creazione di processi remoti che non richiede la riconnessione dinamica. Nulla in questa proposta esclude l'implementazione della riconnessione dinamica in un momento successivo.

2. Proponiamo di aggiungere un "instance tag" all'identificatore di socket, in modo da separare i socket appartenenti a processi diversi dello stesso utente che coesistono su un unico HOST.

3. Sono stati aggiunti i seguenti comandi NCP:

   1. È incluso il comando ERR specificato nell'NWG/RFC 40.

   2. I comandi BLK e RSM sono presentati come possibili alternative al comando IMP "cease on link" e ai comandi SPD e RSM esposti nell'NWG/RFC 36. Poiché questi comandi agiscono sulle connessioni di socket anziché sui numeri di collegamento, non ostacolano l'implementazione del multiplamento delle connessioni di socket su un unico numero di collegamento, qualora in seguito ciò risultasse desiderabile.

   3. Viene specificato un comando INT che interrompe un processo. Riteniamo sia molto importante poter interrompere un processo che magari è impegnato in calcoli o in output non desiderati. Implementare l'interruzione come formato speciale all'interno di un messaggio normale solleva gravi difficoltà: la connessione può essere bloccata proprio quando l'interruzione è necessaria, e l'NCP deve esaminare ogni messaggio in arrivo alla ricerca di un segnale di interruzione.

   4. È incluso un comando di eco ECO per collaudare le comunicazioni tra NCP.

4. I socket sono concepiti come dotati di diversi stati, e questi sono correlati alle condizioni in cui le richieste di rete possono essere messe in coda. Ciò differisce dalla funzione di accodamento illimitato, che presenta talune difficoltà di implementazione.

5. Il protocollo relativo alla creazione di un processo remoto e alla comunicazione con esso viene spostato su un livello di protocollo separato, il protocollo di controllo e comunicazione utente (UCC), ed è specificato più compiutamente.