Annexe : Une application
Il n'existe actuellement qu'un seul réseau informatique de partage de ressources, le réseau ARPA mentionné plus haut. Dans cette annexe, j'espère montrer que le système décrit dans cette note peut s'appliquer au réseau ARPA. Il existe un volume de travaux considérable sur la communication inter-processus au sein du réseau ARPA. Ces travaux se présentent en plusieurs parties presque distinctes : le protocole Host/IMP, le protocole IMP/IMP et le protocole Host/Host. Je suppose le lecteur familier avec ces travaux dans la discussion qui suit. [Voir les références [1][3][4][10][11] ; Specifications for the Inter-connection of a Host to an IMP, BBN Report No. 1822 ; et ARPA Network Working Group Notes #37, 38, 39, 42, 44, 46, 47, 48, 49, 50, 54, 55, 56, 57, 56, 59.]
Dans le réseau ARPA, les IMP ont la seule responsabilité de transmettre correctement les bits d'un site à un autre. Les Host ont la seule responsabilité d'établir les connexions inter-processus. Le Host comme l'IMP s'y intéressent et assument une petite part de responsabilité pour le contrôle de flux et le séquencement des messages. L'application du système de communication inter-processus que j'ai décrit me conduit à une répartition différente des responsabilités. L'IMP continue de déplacer correctement les bits d'un site à un autre, mais le contrôleur de réseau réside lui aussi dans l'IMP, et le contrôle de flux est entièrement entre les mains des processus s'exécutant dans les Host, même s'ils utilisent peut-être des mécanismes fournis par les IMP.
Les IMP fournissent aux Host les opérations SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY et UNIQUE sous des formes légèrement modifiées, et tiennent également les tables de rendez-vous, y compris le déplacement des ports SEND lorsque c'est nécessaire.
Le plus simple est peut-être de reprendre une à une les cinq opérations.
SEND. Le Host donne à l'IMP un numéro de port SEND, un numéro de port RECEIVE, le site de rendez-vous et une spécification de mémoire tampon=20 (par exemple début et fin, début et longueur). Le SEND est envoyé au site de rendez-vous, normalement le site local. Lorsque le RECEIVE correspondant arrive, le Host est averti du port RECEIVE du message de réception qui vient d'arriver. Ce numéro de port suffit à identifier le processus émetteur du SEND, encore qu'un système à temps partagé donné doive peut-être tenir des tables internes faisant correspondre ce numéro de port à des identifiants de processus internes utiles. Simultanément, l'IMP se met à demander au Host des morceaux précis de la mémoire tampon de données. Ces morceaux seront envoyés vers la destination dans la mesure où le permet le contrôle RFNM de l'IMP. Si aucun RFNM n'est reçu pendant trop longtemps, ce qui implique qu'un message a été perdu dans le réseau, le même morceau de données est redemandé au Host [ce qui permet aussi aux messages d'être complètement écartés par le réseau d'IMP, si cela devait un jour être utile], mais le Host a alors la possibilité d'interrompre la transmission. Pendant qu'une transmission a lieu, le Host peut demander à l'IMP 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 ce SEND devient actif dès que la première transmission est terminée. Un troisième SEND identique produit un message d'erreur vers le Host. Si un SEND expire, une erreur est également renvoyée.
RECEIVE. Le Host donne à l'IMP un port SEND, un port RECEIVE, un site de rendez-vous et une description de mémoire tampon. Le message RECEIVE est envoyé au site de rendez-vous. Lorsque des morceaux d'une transmission arrivent pour le port RECEIVE, ils sont passés au Host avec le numéro de port RECEIVE (et peut-être le numéro de port SEND), ainsi qu'une indication au Host de l'endroit où placer les données dans sa mémoire tampon d'entrée. Lorsque le dernier élément de la mémoire tampon SEND est passé au Host, il est marqué en conséquence et le Host peut alors le détecter. Un deuxième RECEIVE sur la même paire de ports est autorisé. Un troisième produit un message d'erreur vers le Host. Le mécanisme décrit dans ce paragraphe et le précédent permet à une paire de processus d'avoir toujours à 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 une mémoire tampon spécifiée, ce qui assure un contrôle de flux complet. (On peut concevoir que le message RECEIVE alloue un morceau de bande passante du réseau pendant sa traversée vers le site de rendez-vous.)
RECEIVE ANY. Le Host donne à l'IMP un port RECEIVE et un descripteur de mémoire tampon. Cela fonctionne comme RECEIVE, mais suppose que le site local est le site de rendez-vous.
SEND FROM ANY. Le Host donne à l'IMP les ports RECEIVE et SEND, le site de destination et un descripteur de mémoire tampon. L'IMP demande et transmet la mémoire tampon aussi vite que possible. Un SEND FROM ANY vers un port inexistant est écarté au site de destination.
Les RFNM sont liés à la transmission d'un morceau précis de mémoire tampon, exactement comme les accusés de réception sont aujourd'hui liés aux paquets, et ils remplissent la même fonction. Si les Host permettent aux IMP de réassembler les mémoires tampons dans les Host, l'IMP indiquant au Host où placer un morceau de mémoire tampon comme décrit ci-dessus, les morceaux d'une même mémoire tampon peuvent être transmis en parallèle et plusieurs RFNM peuvent être en attente simultanément. Le réassemblage des paquets se fait toujours dans les IMP.
Une dernière opération doit être fournie par l'IMP : l'opération UNIQUE. Il existe de nombreuses manières de maintenir des numéros uniques, et trois sont présentées ici. La première possibilité est que les Host demandent au départ les numéros uniques aux IMP, puis garantissent l'intégrité de tous les numéros uniques actuellement détenus par les processus et programmes locaux, par tous les moyens dont le Host dispose. Dans ce cas, les IMP fourniraient une méthode permettant d'envoyer un numéro unique d'un host à un autre et se porteraient garants de l'identité de ce numéro au nouveau site.
La deuxième méthode consiste simplement à donner 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, si un accident survenait, sur les deux mots de passe (ports SEND et RECEIVE) nécessaires pour amorcer une transmission. Si les numéros uniques sont attribué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 à temps partagé garantissent l'intégrité de ces bits d'identification. Ainsi, un processus, sans pouvoir être sûr que c'est le bon port qui lui transmet, peut être sûr que c'est un port du bon utilisateur qui transmet. C'est le concept dit de réseau virtuel (virtual net) suggéré par W. Crowther [3].
Contenu divers. Placer ces opérations dans l'IMP signifie que le programme du protocole Host/Host ne doit être écrit qu'une seule fois, plutôt que de nombreuses fois comme on le fait actuellement dans le réseau ARPA. Les IMP peuvent arrêter la transmission d'un host donné (en ne demandant pas le morceau suivant pendant un moment) si cela semble nécessaire pour atténuer les problèmes d'encombrement dans le sous-réseau de communication. Et l'IMP peut connaître le temps approximatif nécessaire à un RECEIVE pour atteindre tel autre site donné et prévenir le Host de réveiller un processus peu avant qu'il devienne imminent qu'un message destiné à ce processus va arriver.
Note: This RFC was put into machine readable form for entry into the online RFC archives by Katsunori Tanaka 4/99.