Comunicazione tra processi remoti
Il sistema descritto nella sezione precedente si generalizza facilmente per consentire la comunicazione tra processi situati in luoghi geograficamente diversi, come per esempio all'interno di una rete di calcolatori.
Si consideri dapprima una semplice configurazione di processi distribuiti attorno ai punti di una stella. In ciascun punto della stella si trova un sistema time-sharing autonomo. Al centro della stella esiste un sistema di calcolo piuttosto grande e intelligente, chiamato controllore di rete. In questo sistema centrale non può essere eseguito alcun processo; esso va piuttosto considerato un'estensione del monitor di ciascun sistema time-sharing della rete.
Dovrebbe essere evidente al lettore che, se il controllore di rete è in grado di eseguire le operazioni SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY e UNIQUE e se tutti i monitor di tutti i sistemi time-sharing della rete non eseguono essi stessi queste operazioni ma chiedono invece al controllore di rete di eseguirle per loro, allora abbiamo risolto il problema della comunicazione tra processi remoti. Non dobbiamo apportare alcuna ulteriore modifica.
La ragione per cui tutto continua a funzionare quando postuliamo l'esistenza del controllore di rete è che il controllore di rete può tenere traccia di quali RECEIVE sono stati eseguiti e di quali SEND sono stati eseguiti e abbinarli esattamente come faceva il monitor nel modello di sistema time-sharing. È inoltre possibile uno schema di numerazione delle porte valido per tutta la rete, con il controllore di rete che sa dove (ossia presso quale sito) si trova una particolare porta in un dato momento.
Si consideri ora una rete più complessa, in cui non esiste un punto centrale comune, il che rende necessario distribuire tra i nodi della rete le funzioni svolte dal controllore di rete. Nel resto di questa sezione mostrerò che è possibile distribuire in modo efficiente e comodo tra i molti siti della rete le funzioni svolte dal controllore di rete a stella, consentendo comunque una comunicazione generale tra processi remoti.
Occorre apportare alcune modifiche a ciascuna delle quattro operazioni SEND/RECEIVE descritte sopra per adattarle all'uso in una rete distribuita. A RECEIVE si aggiunge un parametro che specifica un sito al quale il RECEIVE deve essere inviato. A SEND FROM ANY e a SEND si aggiunge un sito al quale inviare il SEND, sebbene di norma si tratti del sito locale. Sia RECEIVE sia RECEIVE ANY ricevono l'aggiunta della possibilità di ottenere il sito di origine di ogni messaggio ricevuto. Così, quando viene eseguito un RECEIVE, il RECEIVE viene inviato al sito specificato, eventualmente un sito remoto. Contemporaneamente un SEND viene inviato allo stesso sito, di norma il sito locale del processo che esegue il SEND. Presso questo sito, chiamato sito di rendez-vous, il RECEIVE viene abbinato al SEND appropriato e la trasmissione del messaggio viene consentita verso il sito da cui proveniva il RECEIVE.
Un RECEIVE ANY non lascia mai il suo sito di origine, e in ciò sta la necessità di SEND FROM ANY. Deve essere possibile inviare un messaggio a una porta RECEIVE ANY senza che il messaggio resti bloccato in attesa di un RECEIVE presso il sito mittente. Naturalmente sarebbe possibile costruire il sistema in modo che il rendez-vous SEND/RECEIVE avvenga presso il sito del RECEIVE ed eliminare l'operazione SEND FROM ANY, ma a mio giudizio la possibilità di bloccare una normale trasmissione SEND presso il sito sorgente compensa ampiamente la complessità aggiuntiva.
In qualche punto di ogni sito è tenuta una tabella di rendez-vous. Questa tabella contiene una voce per ogni SEND o RECEIVE non abbinato ricevuto presso quel sito e anche una voce per tutti i RECEIVE ANY dati presso quel sito. Una coppia SEND/RECEIVE abbinata viene cancellata dalla tabella non appena l'abbinamento avviene, o forse quando la trasmissione è completa. Come nella tabella analoga tenuta nel modello di sistema time-sharing, le voci SEND e RECEIVE vanno in timeout se restano non abbinate troppo a lungo e il mittente viene avvisato. Le voci RECEIVE ANY vengono cancellate dalla tabella quando arriva un messaggio che le soddisfa.
L'ultima modifica necessaria per distribuire le funzioni del controllore di rete consiste nel dare a ogni sito una porzione dei numeri unici da distribuire tramite la sua operazione UNIQUE. Tratterò questo argomento più avanti.
Per rendere chiaro al lettore come funziona il controllore di rete distribuito, segue un esempio. I dettagli su quale processo scelga i numeri di porta, ecc. sono solo esemplificativi e non costituiscono uno standard specificato come parte del sistema.
Supponiamo che nella rete vi siano due siti: K e L. Il processo A presso il sito K desidera comunicare con il processo B presso il sito L. Il processo B ha un RECEIVE ANY in sospeso sulla porta M.
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ / \ /
\ / \ port M /
\________/ \____^___/
|
RECEIVE ANY
Fortunatamente, il processo A conosce l'esistenza della porta M presso il sito L e invia messaggi usando l'operazione SEND FROM ANY dalla porta N alla porta M. Il messaggio contiene due numeri di porta e istruzioni affinché il processo B invii messaggi al processo A verso la porta P dalla porta Q. Il numero del sito K viene aggiunto a questo messaggio insieme alla porta SEND N del messaggio.
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ / \ /
\ port N /--->SEND FROM --->\ port M /
\________/ ANY \________/
to port M, site L
containing K, N, P, & Q
Il processo A esegue ora un RECEIVE sulla porta P dalla porta Q. Il processo A specifica il sito L come sito di rendez-vous.
SITE K SITE L
________ R ________
/ \ e / \
/ \ n T/ \
/ \ d a \
| | e b Process B |
| Process A | z l |
| | v e |
\ / o \ /
\ port P / RECEIVE ---> u \ /
\________/ MESSAGE s \________/
to site L
containing P, Q, & K
Un messaggio RECEIVE viene inviato dal sito K al sito L e viene registrato nella tabella di rendez-vous del sito L. In un altro momento, il processo B esegue un SEND verso la porta P dalla porta Q, specificando il sito L come sito di rendez-vous.
SITE K SITE L
________ R ________
/ \ e / \
/ \ n T/ \
/ \ d a \
| | e b Process B |
| Process A | z l |
| | v e |
\ / o \ /
\ port P / u <--- port Q /
\________/ SEND s \________/
to site L
containing P & Q
Il rendez-vous si realizza, la voce della tabella di rendez-vous viene cancellata e ha luogo la trasmissione verso la porta P presso il sito K. Il numero del sito SEND (e verosimilmente il numero della porta SEND) vengono aggiunti ai messaggi della trasmissione a beneficio del processo ricevente.
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ port P / \ port Q /
\ / <---- transmission <---- \ /
\________/ to port T, site K \________/
containing data and L
Il processo B può desiderare contemporaneamente di eseguire un RECEIVE sulla porta M dalla porta N.
Si noti che in questo sistema c'è un solo messaggio di controllo importante che si sposta tra i siti, ossia il tipo di messaggio che in [3] è chiamato messaggio del protocollo Host/Host. Questo messaggio di controllo è il messaggio RECEIVE. Vi sono altri due possibili messaggi di controllo tra siti: un messaggio di errore verso il sito di origine quando un RECEIVE o un SEND va in timeout, e il messaggio SEND nel raro caso in cui il sito di rendez-vous non sia il sito SEND.
Naturalmente deve esistere anche un formato standard per i messaggi tra porte. Per esempio il seguente:
+-----------------+ +-----------------+ +-----------------+
| rendezvous site | | destination site| | source site |
+-----------------+ +-----------------+ +-----------------+
| RECEIVE port | | RECEIVE port | | RECEIVE port |
+-----------------+ +-----------------+ +-----------------+
| SEND port | | SEND port | | SEND port |
+-----------------+ +-----------------+ +-----------------+
| | | source port | | |
| | +-----------------+ | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| data | | data | | data |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
+-----------------+ +-----------------+ +-----------------+
transmitted transmitted received
by SEND by Network by RECEIVE
process Controller process
Nota: per un messaggio SEND FROM ANY, il sito di rendez-vous è il sito di destinazione.
Nel modello di sistema time-sharing era possibile passare una porta da un processo all'altro. Ciò è ancora possibile con un controllore di rete distribuito. [Il lettore non convinto dell'utilità del passaggio delle porte è invitato a leggere la sezione sulla riconnessione in [11].]
Si ricordi che, perché un messaggio sia inviato da un processo a un altro, un SEND verso la porta M dalla porta N e un RECEIVE sulla porta M dalla porta N devono incontrarsi, normalmente presso il sito SEND. Entrambi i processi tengono traccia di dove ritengono che sia il sito di rendez-vous e forniscono questo sito come parametro delle operazioni appropriate. Il processo che esegue il RECEIVE ritiene di essere il sito SEND e il processo che esegue il SEND ritiene normalmente di essere anch'esso il sito SEND. Poiché, non appena un SEND e un RECEIVE si incontrano, la trasmissione viene inviata alla sorgente del RECEIVE e la voce della tabella di rendez-vous viene cancellata e deve essere reimpostata per ogni ulteriore trasmissione da N a M, è facile spostare una porta RECEIVE. Se un processo invia sia i numeri di porta sia il numero del sito di rendez-vous a un nuovo processo presso un altro sito, il quale esegue un RECEIVE usando questi stessi vecchi numeri di porta e questa stessa specifica del sito di rendez-vous, il mittente del SEND non viene mai a sapere che il ricevente si è spostato. È leggermente più difficile spostare una porta SEND. Tuttavia, se ciò accade, la coppia di numeri di porta usata per un SEND e il numero del sito di rendez-vous originale vengono passati al nuovo sito. Il processo presso il nuovo sito SEND specifica il vecchio sito di rendez-vous con il primo SEND dal nuovo sito. Anche il processo che esegue il RECEIVE continuerà a ritenere che il sito di rendez-vous sia il vecchio sito, così il SEND e il RECEIVE si incontreranno presso il vecchio sito. Quando si incontrano, la voce della tabella presso quel sito viene cancellata, il numero del sito di rendez-vous per il messaggio SEND viene cambiato nel sito che ha originato il messaggio SEND ed entrambi i messaggi, SEND e RECEIVE, vengono inviati al nuovo sito SEND, come se fossero stati destinati fin dall'inizio a quel luogo. Il SEND e il RECEIVE si incontrano poi di nuovo presso il nuovo sito di rendez-vous e la trasmissione può continuare come se la porta non si fosse mai spostata. Poiché tutte le trasmissioni contengono il numero del sito di origine, ulteriori RECEIVE verranno inviati al nuovo sito di rendez-vous. È possibile scoprire che questa particolare manipolazione deve avere luogo perché un messaggio SEND viene ricevuto presso un sito che non ha originato il messaggio SEND. Tutto si modifica così facilmente perché non vi sono connessioni permanenti da spezzare e spostare, come nello schema di riconnessione un tempo proposto per la rete ARPA [10][11]; vale a dire, le connessioni esistono solo in modo fugace nel sistema qui descritto e possono quindi essere ricostituite tra qualunque coppia di processi che in qualunque momento vengano a conoscere i numeri di porta l'uno dell'altro e abbiano qualche indizio di dove ciascuno si trovi.
Naturalmente, tutto ciò avrebbe potuto essere fatto dai processi che si inviano messaggi a vicenda annunciando ogni potenziale spostamento e i nuovi numeri di sito.