3. Un système de communication entre processus distants
L'IPC décrit dans la section précédente se généralise facilement pour permettre la communication entre 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 aux points d'une étoile. À chaque point de l'étoile se trouve un système d'exploitation autonome<5>. Un système informatique assez grand et intelligent, appelé contrôleur de réseau (Network Controller), existe au centre de l'étoile. Aucun processus ne peut s'exécuter dans ce système central ; il faut plutôt le considérer comme une extension du moniteur de chacun des systèmes d'exploitation du réseau.
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 eux-mêmes ces opérations mais demandent au contrôleur de réseau de les exécuter pour eux, alors le problème de la communication entre processus distants est résolu. Aucun autre changement n'est nécessaire, car le contrôleur de réseau peut tenir la trace des RECEIVE exécutés et des SEND exécutés et les apparier exactement comme le faisait le moniteur dans le système à temps partagé modèle. 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 sur quel site) se trouve un port particulier à un moment particulier.
Considérons ensuite un réseau plus complexe où il n'existe pas de point central 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 de manière efficace et commode entre les nombreux sites du réseau les fonctions assurées par le contrôleur de réseau en étoile, tout en permettant encore la communication 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 contrôleur de réseau réparti. Au RECEIVE est ajouté un paramètre spécifiant un site auquel le RECEIVE doit être envoyé. Aux messages SEND FROM ANY et SEND est ajouté un site auquel envoyer le SEND, bien qu'il s'agisse normalement du site local. Le RECEIVE et le RECEIVE ANY ont tous deux reçu 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. Sur ce site, appelé site de jonction (rendezvous site), le RECEIVE est apparié au SEND approprié et la transmission du message est autorisée à se faire depuis le site SEND vers le site d'où provient 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, puisqu'il doit être possible d'envoyer un message à un port RECEIVE ANY sans que le message soit bloqué en attente d'un RECEIVE sur le site d'émission. Il est possible de construire un système où la jonction SEND/RECEIVE a lieu sur le site RECEIVE et où l'opération SEND FROM ANY est éliminée, mais à mon jugement la possibilité de bloquer une transmission SEND normale sur le site source compense largement la complexité ajoutée.
Sur chaque site est tenue une table de jonction. Cette table contient une entrée pour chaque SEND ou RECEIVE non apparié reçu sur ce site, ainsi qu'une entrée pour tous les RECEIVE ANY émis sur ce site. Une paire SEND/RECEIVE appariée est effacée de la table dès que l'appariement a lieu. Comme dans la table analogue tenue dans le système à temps partagé modèle, 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 cette question plus loin.
Pour bien montrer au lecteur comment fonctionne le contrôleur de réseau réparti, voici un exemple. Les détails tels que le processus qui choisit les numéros de port ne sont qu'exemplatifs et ne constituent pas une norme spécifiée dans le cadre de l'IPC.
Supposons que, pour deux sites du 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 sur le port M.
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ / \
/ \ / \
| | | |
| Process A | | Process B |
| | | |
\ / \ /
\ / RECEIVE--> port M /
\ / ANY \ /
\______/ \______/
Le processus A connaît heureusement l'existence du port M sur le site L et envoie un message au moyen de l'opération SEND FROM ANY depuis le port N vers le port M. Le message contient deux numéros de port et les instructions demandant au processus B d'envoyer par SEND les messages destinés au processus A du port Q vers le port P. Le numéro de site du site K est ajouté à ce message, en même temps que le port SEND N du message.
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ / \
/ \ / \
| | | |
| Process A | | Process B |
| | | |
\ port N / \ port M /
\ /--->SEND FROM --->\ /
\ / ANY \ /
\______/ \______/
to port M, site L
containing K,N,P, & Q
Le processus A exécute maintenant un RECEIVE sur le port P depuis le port Q. Le processus A spécifie le site L comme site de jonction.
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ Rendezvous/ \
/ \ table \
| | | |
| Process A | ^ | Process B |
| | | | |
\ port P / | \ /
\ / | \ /
\ / <--RECEIVE __/ \ /
\______/ MESSAGE \______/
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 jonction du site L. À un autre moment, le processus B exécute un SEND sur le port P depuis le port Q en spécifiant le site L comme site de jonction.
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ Rendezvous/ \
/ \ table \
| | | |
| Process A | | Process B |
| | | |
\ port P / <--------- port Q /
\ / \ /
\ / SEND \ /
\______/ \______/
to site L
containing P & Q
La jonction s'opère, la table de jonction est effacée, et la transmission vers le port P du site K a lieu. Le numéro du site SEND (et concevablement le numéro du port SEND) est ajouté aux messages de la transmission pour l'édification du processus destinataire.
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ / \
/ \ / \
| | | |
| Process A | | Process B |
| | | |
\ port P / \ port Q /
\ /<--transmission<--\ /
\ / \ /
\______/ to port P, site K \______/
containing data and L
Le processus B peut souhaiter simultanément exécuter un RECEIVE depuis le port N sur le port M.
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 appelé message de protocole Host/Host dans [2]. 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 rare cas où le site de jonction n'est pas le site SEND. Il doit également exister un format standard pour les messages entre ports. Par exemple, ce qui suit :
_________________ __________________ _____________
| rendezvous site | <6> | destination site | | source site |
|-----------------| |------------------| |-------------|
| RECEIVE port | | RECEIVE port | | RECEIVE port|
|-----------------| |------------------| |-------------|
| SEND port | | SEND port | | SEND port |
|-----------------| |------------------| |-------------|
| | | source site | | |
| | |------------------| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| data | | data | | data |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
|_________________| |__________________| |_____________|
transmitted transmitted received
by SEND by Network by RECEIVE
process Controller process
Dans le système à temps partagé modèle, il était possible de transmettre un port d'un processus à un autre. Cela reste possible avec un contrôleur de réseau réparti.
Rappelons que, pour qu'un message soit envoyé d'un processus à un autre, un SEND sur le port M depuis le port N et un RECEIVE sur le port M depuis le port N doivent se rejoindre, normalement sur le site SEND. Les deux processus tiennent la trace de l'endroit où ils croient que se trouve le site de jonction et fournissent ce site comme paramètre des opérations appropriées. Le processus qui exécute le RECEIVE croit lui aussi être le site SEND. Comme, dès qu'un SEND et un RECEIVE se rejoignent, la transmission est envoyée à la source du RECEIVE et l'entrée de la table de jonction 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 jonction à un nouveau processus sur 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 jonction, l'émetteur ne saura jamais que le récepteur a déménagé. Il est un peu plus difficile de déplacer un port d'émission. Toutefois, s'il se déplace, la paire de numéros de port utilisée pour un SEND et le numéro du site de jonction d'origine sont transmis au nouveau site. Le processus du nouveau site SEND spécifie l'ancien site de jonction lors du premier SEND depuis le nouveau site. Le processus RECEIVE croira lui aussi encore que le site de jonction est l'ancien site, si bien que le SEND et le RECEIVE se rencontreront sur l'ancien site. Lorsqu'ils se rencontrent, l'entrée de la table de ce site est effacée, et les messages SEND et RECEIVE sont tous deux 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 sur le nouveau site de jonction et la transmission peut se poursuivre comme si le port n'avait jamais bougé. Comme toutes les transmissions contiennent le numéro du site source, les RECEIVE ultérieurs seront envoyés au nouveau site de jonction. Il est possible de découvrir que cette manipulation spéciale doit avoir lieu parce qu'un message SEND est reçu sur un site qui n'a pas émis ce message SEND<7>. Notons que le port SEND et le port RECEIVE peuvent se déplacer simultanément.
Bien entendu, tout cela aurait aussi pu se faire si les processus s'étaient envoyé des messages annonçant les déplacements éventuels et les nouveaux numéros de site.
Un problème qui a pu venir à l'esprit du lecteur est celui de l'appariement des tailles des tampons SEND et RECEIVE. La solution la plus simple serait d'exiger que tous les tampons aient une taille commune, mais cela est inacceptable car elle ne s'étend pas facilement à une situation où des processus de systèmes d'exploitation autonomes cherchent à communiquer. Une deuxième solution consiste pour les processus à échanger des messages spécifiant les tailles de tampon. Si cette solution est adoptée, les données excessives envoyées par le processus SEND et ne pouvant entrer dans le tampon RECEIVE sont écartées et le processus RECEIVE en est averti. Cette solution a un grand attrait en raison de sa simplicité. Une troisième solution consisterait à transmettre la taille du tampon RECEIVE au site SEND avec le message RECEIVE, et à avertir le processus SEND lorsque trop de données sont envoyées, voire à transmettre la taille du tampon RECEIVE au processus SEND. Cette dernière méthode permettrait aussi au contrôleur de réseau du site SEND de faire deux ou plusieurs SEND à partir d'un seul, si cela était nécessaire pour s'adapter à une taille de tampon RECEIVE plus petite.
La maintenance des numéros uniques est elle aussi un problème lorsque les processus sont répartis géographiquement. Trois solutions à ce problème sont présentées ici. La première possibilité est que les systèmes d'exploitation autonomes demandent au départ les numéros uniques au contrôleur de réseau, puis garantissent l'intégrité des numéros uniques actuellement détenus par les processus et programmes locaux, en utilisant tous les moyens dont dispose le système d'exploitation. Dans ce cas, le contrôleur de réseau fournirait une méthode permettant d'envoyer un numéro unique d'un site à un autre et se porterait garant de l'identité du numéro sur le nouveau site. La deuxième méthode consiste simplement à remettre les numéros uniques aux processus qui les utilisent, en comptant sur le comportement non malveillant des processus pour préserver les numéros uniques, ou, en cas d'accident, sur les deux mots de passe (les numéros de port SEND et RECEIVE) requis pour engager une transmission. Si les numéros uniques sont distribués de manière non séquentielle et sont raisonnablement longs (disons 32 bits), le danger est faible. Dans la dernière méthode, une identification d'utilisateur est incluse dans les numéros de port et les différents systèmes d'exploitation garantissent l'intégrité de ces bits d'identification. Ainsi, un processus, sans pouvoir être sûr que le bon port émet vers lui, peut être sûr que quelque port du bon utilisateur émet. C'est ce qu'on appelle le concept de réseau virtuel (virtual net) proposé par W. Crowther [2].<8>
Un troisième problème difficile se pose lorsque des processus distants souhaitent communiquer : celui du maintien de connexions à haut débit entre les processus distants. La solution à ce problème réside dans le fait de donner aux processus une information considérable sur l'état d'une transmission en cours. Examinons d'abord en détail un processus SEND. Lorsqu'un processus exécute un SEND, la partie locale du contrôleur de réseau transmet le SEND au site de jonction, normalement le site local. Lorsqu'un RECEIVE correspondant à un SEND en attente arrive, le contrôleur de réseau avertit le processus SEND en provoquant une interruption vers l'emplacement de reprise spécifié. Simultanément, le contrôleur de réseau commence à expédier le tampon SEND vers le site RECEIVE. Lorsque la transmission est terminée, un indicateur est positionné, que le processus SEND peut tester. Tandis qu'une transmission a lieu, le processus peut demander au contrôleur de réseau d'exécuter d'autres opérations, y compris d'autres SEND. Un deuxième SEND sur une paire de ports déjà en cours de transmission est noté et le SEND devient actif dès que la première transmission est terminée. Un troisième SEND identique donne lieu à un message d'erreur vers le processus émetteur. Examinons ensuite en détail un processus RECEIVE. Lorsqu'un processus exécute un RECEIVE, le RECEIVE est envoyé au site de jonction. Lorsque les données résultant de ce RECEIVE commencent à arriver sur le site RECEIVE, le processus RECEIVE est averti par une interruption vers l'emplacement de reprise spécifié. Lorsque la transmission est terminée, un indicateur est positionné, que le processus RECEIVE peut tester. Un deuxième RECEIVE sur la même paire de ports est autorisé. Un troisième donne lieu à un message d'erreur vers le processus RECEIVE. Il existe donc un mécanisme suffisant pour permettre à une paire de processus de toujours avoir à la fois une transmission en cours et la suivante en attente. Aucune efficacité n'est donc perdue. En revanche, chaque transmission doit être précédée d'un RECEIVE dans un tampon spécifié, ce qui continue d'assurer un contrôle de flux complet.