4. Une application potentielle

Il n'existe actuellement qu'un seul réseau informatique de partage de ressources, le réseau informatique ARPA. Dans cette section, j'examine l'application du système décrit dans cet article au réseau ARPA [2][5][9].

Le réseau ARPA comprend actuellement dix sites répartis à travers les États-Unis. Chaque site se compose d'un à trois (potentiellement quatre) systèmes informatiques indépendants appelés Hosts et d'un système informatique de communication appelé IMP. Tous les Hosts d'un site sont directement connectés à l'IMP. Les IMPs eux-mêmes sont reliés entre eux par des lignes téléphoniques à 50 kilobits (des lignes à débit bien plus élevé sont envisageables), bien que chaque IMP ne soit connecté qu'à un à cinq autres IMPs. Les IMPs fournissent un sous-réseau de communication par lequel les Hosts communiquent. Les données sont envoyées à travers le sous-réseau de communication sous forme de messages de taille arbitraire (actuellement environ 8000 bits) appelés messages réseau. Lorsqu'un message réseau est reçu par l'IMP du site de destination, cet IMP envoie un accusé de réception, appelé RFNM, au site source.

Un système de communication entre processus pour le réseau ARPA (appelons-le IPC for ARPA) est actuellement conçu par le Network Working Group, sous la présidence de S. Crocker de l'UCLA. Leur conception est quelque peu contrainte par le sous-réseau de communication [5]<9>. J'aimerais comparer point par point l'IPC for ARPA avec celui développé dans cet article ; toutefois, une telle comparaison exigerait d'abord de décrire ici, presque à partir de zéro, l'état actuel de l'IPC for ARPA, car très peu d'informations à jour sur l'IPC for ARPA figurent dans la littérature ouverte [2]. De plus, l'IPC for ARPA est assez complexe et les documents de travail qui le décrivent atteignent maintenant plusieurs centaines de pages, ce qui rendrait toute description longue et inappropriée pour cet article.<10> Je me bornerai donc à quelques comparaisons dispersées des deux systèmes, dont la première est implicite dans ce paragraphe.

Le système de communication entre processus mis au point pour le réseau ARPA se présente en plusieurs parties presque distinctes : le protocole Host/IMP, le protocole IMP/IMP et le protocole Host/Host. Les IMPs ont la seule responsabilité de transmettre correctement les bits d'un site à un autre. Les Hosts ont la seule responsabilité d'établir les connexions entre processus. Le Host et l'IMP sont tous deux concernés 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 entre processus décrit dans cet article m'amène à faire 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 aussi dans l'IMP, et le contrôle de flux est entièrement entre les mains des processus s'exécutant dans les Hosts, bien qu'utilisant les mécanismes fournis par les IMPs.

Les IMPs fournissent aux Hosts 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 jonction, y compris le déplacement des ports SEND lorsque c'est nécessaire. Placer ces opérations dans l'IMP exige que le programme du protocole Host/Host ne soit écrit qu'une seule fois, plutôt que de nombreuses fois comme on le fait actuellement dans le réseau ARPA. Il est peut-être utile de reprendre les cinq opérations une à une.

SEND. Le Host donne à l'IMP un numéro de port SEND, un numéro de port RECEIVE, le site de jonction et une spécification de tampon (par exemple, début et fin, ou début et longueur). Le SEND est envoyé à l'IMP du site de jonction, normalement l'IMP local. Lorsqu'un RECEIVE correspondant arrive à l'IMP local, le Host est averti du port RECEIVE du message qui vient d'arriver. Ce numéro de port suffit à identifier le processus émetteur, bien qu'un système d'exploitation donné puisse devoir tenir des tables internes faisant correspondre ce numéro de port à un identifiant de processus interne utile. Simultanément, l'IMP commence à demander au Host des morceaux précis du tampon SEND, en envoyant ces morceaux sous forme de messages réseau vers le site de destination. Si aucun RFNM n'est reçu pendant trop longtemps, ce qui implique qu'un message réseau a été perdu dans le réseau, les mêmes données sont redemandées au Host et retransmises.<11> À l'exception du dernier morceau d'un tampon, l'IMP demande au Host des morceaux qui sont des multiples communs de la taille de mot du Host source, de l'IMP et du Host de destination. Cela évite les problèmes d'alignement de mots en cours de transmission.

RECEIVE. Le Host donne à l'IMP un port SEND, un port RECEIVE, un site de jonction et une description de tampon. Le message RECEIVE est envoyé au site de jonction. Au fur et à mesure que les messages réseau composant une transmission arrivent pour le port RECEIVE, ils sont remis 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 ces données dans son tampon d'entrée. Lorsque le dernier message réseau du tampon SEND est remis au Host, il est marqué en conséquence et le Host peut alors le détecter. (Il est concevable que le message RECEIVE puisse aussi allouer une partie de la bande passante du réseau pendant sa traversée du réseau vers le site de jonction.)

RECEIVE ANY. Le Host donne à l'IMP un port RECEIVE et un descripteur de tampon. Cela fonctionne comme RECEIVE, mais suppose que le site local est le site de jonction.

SEND FROM ANY. Le Host donne à l'IMP les ports RECEIVE et SEND, le site de destination et un descripteur de tampon. L'IMP demande et transmet le tampon aussi vite que possible. Un SEND FROM ANY visant un port inexistant est écarté au site de destination.

Dans le réseau ARPA, les IMPs exigent des Hosts qu'ils découpent physiquement leurs transmissions en messages réseau, et les messages successifs d'une même transmission doivent être différés jusqu'à réception du RFNM du message précédent. Dans le système décrit ici, comme les RFNM sont liés à la transmission d'un morceau de tampon particulier et que les Hosts permettent aux IMPs de réassembler les tampons dans les Hosts en indiquant au Host où placer chaque morceau de tampon, les morceaux d'un même tampon peuvent être transmis dans des messages réseau parallèles et plusieurs RFNM peuvent être en attente simultanément. Cela permet aux Hosts de traiter des transmissions de tailles plus naturelles et un débit plus élevé pour une même transmission.

Pour plus d'efficacité, l'IMP pourrait connaître le temps approximatif nécessaire à un RECEIVE pour atteindre tel autre site et avertir le Host de réveiller un processus peu avant l'arrivée imminente d'un message destiné à ce processus.