4. Una potenziale applicazione

Attualmente esiste una sola rete di calcolatori con condivisione di risorse, la rete di calcolatori ARPA. In questa sezione discuto l'applicazione del sistema descritto in questo articolo alla rete ARPA [2][5][9].

La rete ARPA comprende attualmente dieci siti distribuiti negli Stati Uniti. Ogni sito è costituito da uno a tre (potenzialmente quattro) sistemi di calcolatori indipendenti detti Host e da un sistema di calcolatori per le comunicazioni detto IMP. Tutti gli Host di un sito sono direttamente collegati all'IMP. Gli IMP stessi sono collegati tra loro da linee telefoniche a 50 kilobit (linee a velocità molto più elevata sono una possibilità), sebbene ogni IMP sia collegato solo da uno a cinque altri IMP. Gli IMP forniscono una sottorete di comunicazione attraverso la quale gli Host comunicano. I dati vengono inviati attraverso la sottorete di comunicazione in messaggi di dimensione arbitraria (attualmente circa 8000 bit) detti messaggi di rete. Quando un messaggio di rete viene ricevuto dall'IMP nel sito di destinazione, quell'IMP invia un'accusa di ricezione, detta RFNM, al sito di origine.

Un sistema di comunicazione tra processi per la rete ARPA (chiamiamolo IPC for ARPA) è attualmente in fase di progettazione da parte del Network Working Group, sotto la presidenza di S. Crocker dell'UCLA. Il loro progetto è alquanto vincolato dalla sottorete di comunicazione [5]<9>. Vorrei confrontare punto per punto IPC for ARPA con quello sviluppato in questo articolo; tuttavia, un tale confronto richiederebbe anzitutto di descrivere qui, quasi da zero, lo stato attuale di IPC for ARPA, poiché nella letteratura aperta compare pochissima informazione aggiornata su IPC for ARPA [2]. Inoltre IPC for ARPA è piuttosto complesso e i documenti di lavoro che lo descrivono ammontano ormai a molte centinaia di pagine, rendendo qualsiasi descrizione lunga e inappropriata per questo articolo.<10> Mi limiterò quindi ad alcuni sparsi confronti tra i due sistemi, il primo dei quali è implicito in questo paragrafo.

Il sistema di comunicazione tra processi in fase di sviluppo per la rete ARPA si presenta in diverse parti quasi distinte: il protocollo Host/IMP, il protocollo IMP/IMP e il protocollo Host/Host. 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 interessati e si assumono una piccola responsabilità per il controllo di flusso e la sequenza dei messaggi. L'applicazione del sistema di comunicazione tra processi descritto in questo articolo mi porta a una diversa ripartizione delle responsabilità. L'IMP continua a spostare correttamente i bit da un sito a un altro, ma il controllore di rete risiede anch'esso nell'IMP, e il controllo di flusso è interamente nelle mani dei processi in esecuzione negli Host, pur usando i 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 anche le tabelle di incontro, compreso lo spostamento delle porte SEND quando necessario. Collocare queste operazioni nell'IMP richiede che il programma del protocollo Host/Host sia scritto una sola volta, anziché molte volte come si fa attualmente nella rete ARPA. È forse utile ripercorrere le cinque operazioni una per una.

SEND. L'Host dà all'IMP un numero di porta SEND, un numero di porta RECEIVE, il sito di incontro e una specifica del buffer (per esempio inizio e fine, oppure inizio e lunghezza). Il SEND viene inviato all'IMP del sito di incontro, normalmente l'IMP locale. Quando un RECEIVE corrispondente arriva all'IMP locale, l'Host viene avvisato della porta RECEIVE del messaggio appena arrivato. Questo numero di porta è sufficiente a identificare il processo che ha eseguito il SEND, sebbene un dato sistema operativo possa dover tenere tabelle interne che mappano questo numero di porta in un utile identificatore interno di processo. Contemporaneamente l'IMP inizia a chiedere all'Host pezzi specifici del buffer SEND, inviando questi pezzi come messaggi di rete al sito di destinazione. Se non viene ricevuto alcun RFNM per troppo tempo, il che implica che un messaggio di rete è andato perduto nella rete, gli stessi dati vengono richiesti di nuovo all'Host e ritrasmessi.<11> Fatta eccezione per l'ultimo pezzo di un buffer, l'IMP chiede all'Host pezzi che sono multipli comuni della dimensione di parola dell'Host di origine, dell'IMP e dell'Host di destinazione. Ciò evita problemi di allineamento delle parole durante la trasmissione.

RECEIVE. L'Host dà all'IMP una porta SEND, una porta RECEIVE, un sito di incontro e una descrizione del buffer. Il messaggio RECEIVE viene inviato al sito di incontro. Man mano che i messaggi di rete che compongono una trasmissione arrivano 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 questi dati nel suo buffer di ingresso. Quando l'ultimo messaggio di rete del buffer SEND viene passato all'Host, esso viene contrassegnato di conseguenza e l'Host può quindi rilevarlo. (È concepibile che il messaggio RECEIVE possa anche allocare una porzione di larghezza di banda della rete mentre compie il suo percorso verso il sito di incontro.)

RECEIVE ANY. L'Host dà all'IMP una porta RECEIVE e un descrittore di buffer. Funziona come RECEIVE ma presume che il sito locale sia il sito di incontro.

SEND FROM ANY. L'Host dà 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ù rapidamente possibile. Un SEND FROM ANY per una porta inesistente viene scartato nel sito di destinazione.

Nella rete ARPA gli IMP richiedono agli Host di spezzare fisicamente le loro trasmissioni in messaggi di rete, e i messaggi successivi di una singola trasmissione devono essere ritardati finché non si riceve l'RFNM del messaggio precedente. Nel sistema qui descritto, poiché gli RFNM sono legati alla trasmissione di un particolare pezzo di buffer e poiché gli Host consentono agli IMP di riassemblare i buffer negli Host, indicando all'Host dove collocare ogni pezzo di buffer, i pezzi di un singolo buffer possono essere trasmessi in messaggi di rete paralleli e più RFNM possono essere in sospeso contemporaneamente. Ciò consente agli Host di gestire trasmissioni di dimensioni più naturali e una larghezza di banda più elevata per una singola trasmissione.

Per ulteriore efficienza, l'IMP potrebbe conoscere il tempo approssimativo che un RECEIVE impiega a raggiungere un particolare altro sito e avvisare l'Host di svegliare un processo poco prima che l'arrivo di un messaggio per quel processo sia imminente.