Aller au contenu principal

I - Introduction

Dans ce document, le groupe de travail sur les réseaux du MIT Project MAC propose des modifications et des extensions au protocole spécifié par Carr, Crocker et Cerf dans un pré-tirage de leur article pour la SJCC de 1970, et étendu par Crocker dans le NWG/RFC 36. Ce document esquisse largement notre proposition mais ne prétend pas être une spécification complète. Il est destiné à indiquer le type et l'ampleur du protocole qui, selon nous, devraient être mis en œuvre au départ.

Nous sommes d'accord avec le concept de base d'une communication simplex entre des sockets ayant des identificateurs uniques. Nous proposons la mise en œuvre d'un sous-ensemble légèrement modifié des commandes de réseau spécifiées dans le NWG/RFC36, plus la commande ERR telle que spécifiée par Harslem et Heafner dans le NWG/RFC 40.

Étant donné l'objectif de base consistant à raccorder tous les contractants de l'ARPA au réseau et à leur permettre de communiquer entre eux le plus tôt possible, nous estimons important de mettre en œuvre un protocole initial raisonnablement simple mais extensible, tout en répondant aux principaux usages initiaux du réseau. Il doit être simple afin de susciter le soutien le plus large possible et d'être facile à mettre en œuvre dans toutes les installations avec un minimum de logiciel supplémentaire.

Le protocole évoluera, mais les fondements d'un protocole accepté et mis en œuvre par toutes les installations se révéleront probablement très résistants au changement. Il est donc très important de rendre le protocole initial ouvert et souple. Un protocole de base simple a plus de chances de réussir à cet égard qu'un protocole compliqué. Cela n'exclut pas l'existence de couches de protocole supplémentaires entre plusieurs installations, tant que le protocole de base reste pris en charge.

Nous estimons que trois facilités doivent être prévues dans le protocole initial:

  1. La communication multi-chemin entre deux processus existants qui savent comment se connecter l'un à l'autre.

  2. Un moyen standard pour qu'un processus se connecte au logger (processus d'enregistrement sur un HOST) d'un HOST étranger et demande la création d'un processus utilisateur. (Le rituel de connexion peut être standardisé ou non.)

  3. Un moyen standard pour qu'un processus nouvellement créé engage une communication pseudo-téléscripteur avec le processus étranger qui a demandé sa création.

Les principales différences entre le protocole proposé par Carr, Crocker et Cerf et cette proposition sont les suivantes:

  1. La stratégie de reconnexion dynamique spécifiée par Crocker dans le NWG/RFC 36 est réservée à une mise en œuvre ultérieure. Nous estimons que son inclusion compliquerait indûment la mise en œuvre initiale du protocole. Nous esquissons une stratégie de création de processus étranger qui n'exige pas de reconnexion dynamique. Rien dans cette proposition n'exclut la mise en œuvre ultérieure de la reconnexion dynamique.

  2. Nous proposons d'ajouter un "instance tag" à l'identificateur de socket afin de distinguer les sockets appartenant à des processus différents d'un même utilisateur coexistant sur un même HOST.

  3. Les commandes NCP suivantes ont été ajoutées:

    1. La commande ERR spécifiée dans le NWG/RFC 40 est incluse.

    2. Les commandes BLK et RSM sont présentées comme des solutions de remplacement possibles à la commande IMP "cease on link" et aux commandes SPD et RSM exposées dans le NWG/RFC 36. Comme ces commandes agissent sur des connexions de socket plutôt que sur des numéros de lien, elles ne font pas obstacle à la mise en œuvre d'un multiplexage de connexions de socket sur un seul numéro de lien, si cela se révélait souhaitable par la suite.

    3. Une commande INT qui interrompt un processus est spécifiée. Nous estimons qu'il est très important de pouvoir interrompre un processus qui se livre peut-être à des calculs ou à des sorties non désirés. Mettre en œuvre l'interruption sous la forme d'un format spécial à l'intérieur d'un message normal soulève de sérieuses difficultés: la connexion peut être bloquée au moment où l'interruption est nécessaire, et le NCP doit examiner chaque message entrant à la recherche d'un signal d'interruption.

    4. Une commande d'écho ECO destinée à tester les communications entre NCP est incluse.

  4. Les sockets sont conçus comme ayant plusieurs états, et ceux-ci sont liés aux conditions dans lesquelles les demandes de réseau peuvent être mises en file. Cela diffère de la fonction de mise en file illimitée, qui présente certaines difficultés de mise en œuvre.

  5. Le protocole concernant la création d'un processus étranger et la communication avec celui-ci est déplacé vers un niveau de protocole distinct, le protocole de contrôle et de communication utilisateur (UCC), et y est spécifié plus complètement.