Communication inter-processus entre processus distants
Le système décrit dans la section précédente se généralise aisément pour permettre la communication inter-processus entre des processus situés en des lieux géographiquement différents, comme par exemple au sein d'un réseau informatique.
Considérons d'abord une configuration simple de processus répartis autour des branches d'une étoile. À chaque branche de l'étoile se trouve un système à temps partagé autonome. Un système informatique assez grand et intelligent, appelé contrôleur de réseau, existe au centre de l'étoile. Aucun processus ne peut s'exécuter dans ce système central, qui doit plutôt être considéré comme une extension du moniteur de chaque système à temps partagé du réseau.
Il devrait être évident pour le lecteur que si le contrôleur de réseau est capable d'exécuter les opérations SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY et UNIQUE, et si tous les moniteurs de tous les systèmes à temps partagé du réseau n'exécutent pas ces opérations eux-mêmes mais demandent plutôt au contrôleur de réseau de les exécuter pour eux, alors nous avons résolu le problème de la communication inter-processus entre processus distants. Nous n'avons plus aucune modification à apporter.
Si tout continue de fonctionner lorsque nous postulons l'existence du contrôleur de réseau, c'est que celui-ci peut tenir la comptabilité des RECEIVE exécutés et des SEND exécutés, et les apparier exactement comme le faisait le moniteur dans le modèle de système à temps partagé. Un schéma de numérotation des ports valable pour tout le réseau est également possible, le contrôleur de réseau sachant où (c'est-à-dire à quel site) se trouve un port donné à un moment donné.
Considérons ensuite un réseau plus complexe, dans lequel il n'existe aucun centre commun, ce qui rend nécessaire de répartir entre les nœuds du réseau les fonctions assurées par le contrôleur de réseau. Dans le reste de cette section, je montrerai qu'il est possible de répartir efficacement et commodément entre les nombreux sites du réseau les fonctions assurées par le contrôleur de réseau en étoile, tout en permettant une communication inter-processus générale entre processus distants.
Certaines modifications doivent être apportées à chacune des quatre opérations SEND/RECEIVE décrites ci-dessus pour les adapter à un réseau distribué. Au RECEIVE s'ajoute un paramètre spécifiant un site auquel le RECEIVE doit être envoyé. Au SEND FROM ANY et au SEND s'ajoute un site auquel envoyer le SEND, bien qu'il s'agisse normalement du site local. Le RECEIVE et le RECEIVE ANY se voient tous deux ajouter la possibilité d'obtenir le site source de tout message reçu. Ainsi, lorsqu'un RECEIVE est exécuté, le RECEIVE est envoyé au site spécifié, éventuellement un site distant. Simultanément, un SEND est envoyé au même site, normalement le site local du processus qui exécute le SEND. En ce site, appelé site de rendez-vous, le RECEIVE est apparié au SEND approprié et la transmission du message est autorisée vers le site d'où provenait le RECEIVE.
Un RECEIVE ANY ne quitte jamais son site d'origine, et c'est là que réside la nécessité de SEND FROM ANY. Il doit être possible d'envoyer un message vers un port RECEIVE ANY sans que ce message reste bloqué en attente d'un RECEIVE au site émetteur. Bien sûr, il serait possible de construire le système de façon que le rendez-vous SEND/RECEIVE ait lieu au site du RECEIVE et de supprimer l'opération SEND FROM ANY, mais selon mon jugement la possibilité de bloquer une transmission SEND normale au site source compense largement la complexité supplémentaire.
Quelque part à chaque site est tenue une table de rendez-vous. Cette table contient une entrée pour chaque SEND ou RECEIVE non apparié reçu à ce site, ainsi qu'une entrée pour tous les RECEIVE ANY donnés à ce site. Une paire SEND/RECEIVE qui s'apparie est effacée de la table dès que l'appariement a lieu, ou peut-être lorsque la transmission est terminée. Comme dans la table analogue tenue dans le modèle de système à temps partagé, les entrées SEND et RECEIVE expirent si elles restent non appariées trop longtemps, et l'émetteur en est averti. Les entrées RECEIVE ANY sont effacées de la table lorsqu'un message qui les satisfait arrive.
La dernière modification nécessaire pour répartir les fonctions du contrôleur de réseau consiste à donner à chaque site une portion des numéros uniques à distribuer via son opération UNIQUE. J'examinerai ce point plus loin.
Pour bien montrer au lecteur comment fonctionne le contrôleur de réseau réparti, un exemple suit. Les détails de savoir quel processus choisit les numéros de port, etc. ne sont qu'exemplatifs et ne constituent pas une norme spécifiée comme faisant partie du système.
Supposons qu'il y ait deux sites dans le réseau : K et L. Le processus A du site K souhaite communiquer avec le processus B du site L. Le processus B a un RECEIVE ANY en attente au port M.
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ / \ /
\ / \ port M /
\________/ \____^___/
|
RECEIVE ANY
Heureusement, le processus A connaît l'existence du port M au site L et envoie des messages au moyen de l'opération SEND FROM ANY, du port N au port M. Le message contient deux numéros de port et des instructions demandant au processus B d'envoyer des messages au processus A vers le port P depuis le port Q. Le numéro du site K est ajouté à ce message, ainsi que le port SEND N de ce message.
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
Le processus A exécute maintenant un RECEIVE au port P depuis le port Q. Le processus A spécifie le site L comme site de 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 message RECEIVE est envoyé du site K au site L et est inscrit dans la table de rendez-vous du site L. À un autre moment, le processus B exécute un SEND vers le port P depuis le port Q, en spécifiant le site L comme site de 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
Un rendez-vous est établi, l'entrée de la table de rendez-vous est effacée, et la transmission vers le port P du site K a lieu. Le numéro du site SEND (et éventuellement le numéro du port SEND) sont ajoutés aux messages de la transmission, à l'intention du processus récepteur.
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ port P / \ port Q /
\ / <---- transmission <---- \ /
\________/ to port T, site K \________/
containing data and L
Le processus B peut souhaiter simultanément exécuter un RECEIVE au port M depuis le port N.
Notons qu'il n'existe qu'un seul message de contrôle important circulant entre les sites dans ce système : le type de message que [3] appelle message de protocole Host/Host. Ce message de contrôle est le message RECEIVE. Il existe deux autres messages de contrôle intersites possibles : un message d'erreur vers le site d'origine lorsqu'un RECEIVE ou un SEND expire, et le message SEND dans le cas rare où le site de rendez-vous n'est pas le site SEND.
Bien sûr, il doit aussi exister un format standard pour les messages entre ports. Par exemple le suivant :
+-----------------+ +-----------------+ +-----------------+
| 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
Remarque : pour un message SEND FROM ANY, le site de rendez-vous est le site de destination.
Dans le modèle de système à temps partagé, il était possible de transmettre un port d'un processus à un autre. Cela reste possible avec un contrôleur de réseau distribué. [Le lecteur qui n'est pas convaincu de l'utilité de la transmission de ports est invité à lire la section consacrée à la reconnexion dans [11].]
Rappelons que pour qu'un message soit envoyé d'un processus à un autre, un SEND vers le port M depuis le port N et un RECEIVE au port M depuis le port N doivent se donner rendez-vous, normalement au site SEND. Les deux processus gardent la trace de l'endroit où ils croient que se trouve le site de rendez-vous et fournissent ce site comme paramètre des opérations appropriées. Le processus qui exécute le RECEIVE croit être le site SEND, et le processus qui exécute le SEND croit normalement être lui aussi le site SEND. Comme, dès qu'un SEND et un RECEIVE se donnent rendez-vous, la transmission est envoyée à la source du RECEIVE et l'entrée de la table de rendez-vous est effacée et doit être rétablie pour chaque transmission ultérieure de N vers M, il est facile de déplacer un port RECEIVE. Si un processus envoie à la fois les numéros de port et le numéro du site de rendez-vous à un nouveau processus situé à un autre site, lequel exécute un RECEIVE en utilisant ces mêmes anciens numéros de port et cette même spécification de site de rendez-vous, l'émetteur du SEND ne sait jamais que le récepteur du RECEIVE s'est déplacé. Il est légèrement plus difficile de déplacer un port SEND. Cependant, si cela se produit, la paire de numéros de port utilisée pour un SEND et le numéro du site de rendez-vous d'origine sont transmis au nouveau site. Le processus du nouveau site SEND spécifie l'ancien site de rendez-vous lors du premier SEND depuis le nouveau site. Le processus qui exécute le RECEIVE continuera lui aussi de croire que le site de rendez-vous est l'ancien site, de sorte que le SEND et le RECEIVE se rencontreront à l'ancien site. Lorsqu'ils se rencontrent, l'entrée de la table de ce site est effacée, le numéro du site de rendez-vous du message SEND est remplacé par le site qui a émis le message SEND, et les deux messages, SEND et RECEIVE, sont envoyés au nouveau site SEND, exactement comme s'ils y avaient été destinés dès le départ. Le SEND et le RECEIVE se rencontrent alors de nouveau au nouveau site de rendez-vous et la transmission peut se poursuivre comme si le port ne s'était jamais déplacé. Comme toutes les transmissions contiennent le numéro du site source, les RECEIVE ultérieurs seront envoyés au nouveau site de rendez-vous. Il est possible de détecter que cette manipulation particulière doit avoir lieu parce qu'un message SEND est reçu à un site qui n'a pas émis ce message SEND. Tout se modifie si facilement parce qu'il n'existe aucune connexion permanente à rompre et à déplacer, contrairement au schéma de reconnexion autrefois proposé pour le réseau ARPA [10][11] : autrement dit, les connexions n'existent que de façon fugace dans le système décrit ici et peuvent donc être rétablies entre n'importe quelle paire de processus qui, à un moment donné, connaissent les numéros de port l'un de l'autre et ont quelque indice de l'endroit où ils se trouvent.
Bien sûr, tout cela aurait pu être fait par les processus s'envoyant des messages pour annoncer tout déplacement éventuel et les nouveaux numéros de site.