Appendice: Un'applicazione
Attualmente esiste una sola rete di calcolatori per la condivisione di risorse, la già citata rete ARPA. In questa appendice spero di mostrare che il sistema descritto in questa nota può essere applicato alla rete ARPA. Esiste già un corpo considerevole di lavori sulla comunicazione tra processi all'interno della rete ARPA. Questi lavori si presentano in diverse parti quasi distinte: il protocollo Host/IMP, il protocollo IMP/IMP e il protocollo Host/Host. Nella discussione che segue presumo la familiarità con questi lavori. [Vedere i riferimenti [1][3][4][10][11]; Specifications for the Inter-connection of a Host to an IMP, BBN Report No. 1822; e ARPA Network Working Group Notes #37, 38, 39, 42, 44, 46, 47, 48, 49, 50, 54, 55, 56, 57, 56, 59.]
Nella rete ARPA gli IMP hanno la sola responsabilità di trasmettere correttamente i bit da un sito a un altro. Gli Host hanno la sola responsabilità di stabilire le connessioni tra processi. Sia l'Host sia l'IMP sono coinvolti e si assumono una piccola parte di responsabilità per il controllo di flusso e la sequenziazione dei messaggi. L'applicazione del sistema di comunicazione tra processi che ho descritto mi porta a una diversa ripartizione delle responsabilità. L'IMP continua a spostare correttamente i bit da un sito a un altro, ma anche il controllore di rete risiede nell'IMP, e il controllo di flusso è completamente nelle mani dei processi in esecuzione negli Host, sebbene essi usino forse meccanismi forniti dagli IMP.
Gli IMP forniscono agli Host le operazioni SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY e UNIQUE in forme leggermente modificate e mantengono inoltre le tabelle di rendez-vous, incluso lo spostamento delle porte SEND quando è necessario.
Forse il modo più semplice è ripercorrere le cinque operazioni una per una.
SEND. L'Host fornisce all'IMP un numero di porta SEND, un numero di porta RECEIVE, il sito di rendez-vous e una specifica di buffer=20 (per esempio inizio e fine, inizio e lunghezza). Il SEND viene inviato al sito di rendez-vous, di norma il sito locale. Quando arriva il RECEIVE corrispondente, l'Host viene informato della porta RECEIVE del messaggio di ricezione appena arrivato. Questo numero di porta è sufficiente a identificare il processo mittente del SEND, sebbene un dato sistema time-sharing possa dover tenere tabelle interne che associano questo numero di porta a utili identificatori interni di processo. Contemporaneamente l'IMP inizia a chiedere all'Host blocchi specifici del buffer di dati. Questi blocchi verranno inviati a destinazione per quanto consentito dal controllo RFNM dell'IMP. Se non viene ricevuto alcun RFNM per troppo tempo, il che implica che un messaggio è andato perduto nella rete, all'Host viene richiesto di nuovo lo stesso blocco di dati [il che consente anche ai messaggi di essere completamente scartati dalla rete di IMP, se mai ciò dovesse risultare utile], ma a questo punto l'Host ha la possibilità di interrompere la trasmissione. Mentre una trasmissione è in corso, l'Host può chiedere all'IMP di eseguire altre operazioni, compresi altri SEND. Un secondo SEND su una coppia di porte già in corso di trasmissione viene annotato e il SEND diventa attivo non appena la prima trasmissione è completa. Un terzo SEND identico produce un messaggio di errore verso l'Host. Se un SEND va in timeout, viene restituito un errore analogamente.
RECEIVE. L'Host fornisce all'IMP una porta SEND, una porta RECEIVE, un sito di rendez-vous e una descrizione di buffer. Il messaggio RECEIVE viene inviato al sito di rendez-vous. Quando arrivano blocchi di una trasmissione per la porta RECEIVE, essi vengono passati all'Host insieme al numero di porta RECEIVE (e forse al numero di porta SEND) e a un'indicazione all'Host su dove collocare i dati nel suo buffer di ingresso. Quando l'ultimo elemento del buffer SEND è passato nell'Host, esso viene contrassegnato di conseguenza e l'Host può allora rilevarlo. Un secondo RECEIVE sulla stessa coppia di porte è consentito. Un terzo produce un messaggio di errore verso l'Host. Il meccanismo descritto in questo e nel precedente paragrafo consente a una coppia di processi di avere sempre sia una trasmissione in corso sia la successiva in attesa. Non si perde quindi alcuna efficienza. D'altro canto, ogni trasmissione deve essere preceduta da un RECEIVE in un buffer specificato, il che fornisce un controllo di flusso completo. (È concepibile che il messaggio RECEIVE possa allocare un pezzo di banda della rete mentre compie la sua traversata verso il sito di rendez-vous.)
RECEIVE ANY. L'Host fornisce all'IMP una porta RECEIVE e un descrittore di buffer. Funziona come RECEIVE, ma presume che il sito locale sia il sito di rendez-vous.
SEND FROM ANY. L'Host fornisce all'IMP le porte RECEIVE e SEND, il sito di destinazione e un descrittore di buffer. L'IMP richiede e trasmette il buffer il più velocemente possibile. Un SEND FROM ANY verso una porta inesistente viene scartato presso il sito di destinazione.
Gli RFNM sono legati alla trasmissione di un particolare blocco di buffer esattamente come le conferme oggi sono legate ai pacchetti, e svolgono la stessa funzione. Se gli Host permettono agli IMP di riassemblare i buffer negli Host, con l'IMP che indica all'Host dove collocare un blocco di buffer come descritto sopra, i blocchi di un singolo buffer possono essere trasmessi in parallelo e più RFNM possono essere contemporaneamente in sospeso. Il riassemblaggio dei pacchetti è ancora effettuato negli IMP.
Un'ultima operazione deve essere fornita dall'IMP: l'operazione UNIQUE. Esistono molti modi per mantenere numeri unici e tre sono presentati qui. La prima possibilità è che gli Host chiedano inizialmente agli IMP i numeri unici e garantiscano poi l'integrità di tutti i numeri unici attualmente posseduti da processi e programmi locali, con qualunque mezzo l'Host abbia a disposizione. In questo caso gli IMP fornirebbero un metodo perché un numero unico sia inviato da un host a un altro e garantirebbero l'identità del numero presso il nuovo sito.
Il secondo metodo consiste semplicemente nel dare i numeri unici ai processi che li usano, facendo affidamento sul comportamento non malevolo dei processi per preservare i numeri unici, oppure, se dovesse accadere un incidente, sulle due password (porte SEND e RECEIVE) necessarie per avviare una trasmissione. Se i numeri unici vengono distribuiti in modo non sequenziale e sono ragionevolmente lunghi (diciamo 32 bit), il pericolo è scarso.
Nell'ultimo metodo, un'identificazione dell'utente è inclusa nei numeri di porta e i singoli sistemi time-sharing garantiscono l'integrità di questi bit di identificazione. Così un processo, pur non potendo essere certo che sia la porta corretta a trasmettere verso di lui, può essere certo che sia qualche porta dell'utente corretto a trasmettere. Questo è il cosiddetto concetto di rete virtuale (virtual net) suggerito da W. Crowther [3].
Contenuti vari. Collocare queste operazioni nell'IMP significa che il programma del protocollo Host/Host deve essere scritto una sola volta, anziché molte volte come si fa attualmente nella rete ARPA. Gli IMP possono fermare la trasmissione di un host specifico (non chiedendo il blocco successivo per un po') se ciò dovesse sembrare necessario per alleviare i problemi di congestione nella sottorete di comunicazione. E l'IMP potrebbe conoscere il tempo approssimativo che un RECEIVE impiega per raggiungere un particolare altro sito e avvisare l'Host di risvegliare un processo poco prima che diventi imminente l'arrivo di un messaggio per quel processo.
Note: This RFC was put into machine readable form for entry into the online RFC archives by Katsunori Tanaka 4/99.