Aller au contenu principal

RFC 1 - Logiciel hôte (Host Software)

Groupe de travail réseau (Network Working Group) : Steve Crocker
Demande de commentaires (Request for Comments) : 1
Institution : UCLA
Date : 7 avril 1969

Résumé​

Ce document est le premier RFC de l'histoire de l'ARPANET, discutant des considérations de conception pour le logiciel hôte. Le document couvre un aperçu du logiciel IMP (Interface Message Processor, processeur de messages d'interface), les exigences pour le logiciel hôte-à-hôte, les mécanismes d'établissement de connexion et les plans d'expériences préliminaires. Ce document marque le début de la tradition de documentation des protocoles Internet.

CONTENU (CONTENTS)​

INTRODUCTION​

Le logiciel pour le réseau ARPA existe en partie dans les IMP et en partie dans les hôtes (HOSTs) respectifs. BB&N a spécifié le logiciel des IMP et il est de la responsabilité des groupes hôtes de s'accorder sur le logiciel hôte.

Pendant l'été 1968, des représentants des quatre sites initiaux se sont réunis plusieurs fois pour discuter du logiciel hôte et des expériences initiales sur le réseau. De ces réunions est né un groupe de travail de trois personnes, Steve Carr de l'Utah, Jeff Rulifson de SRI et Steve Crocker de UCLA, qui se sont rencontrés pendant l'automne et l'hiver. La réunion la plus récente a eu lieu la dernière semaine de mars dans l'Utah. Bill Duvall de SRI, qui a récemment commencé à travailler avec Jeff Rulifson, était également présent.

De manière quelque peu indépendante, Gerard DeLoche de UCLA a travaillé sur l'interface hôte-IMP.

Je présente ici certains des accords provisoires atteints et certaines des questions ouvertes rencontrées. Très peu de ce qui est ici est définitif et des réactions sont attendues.

I. Un résumé du logiciel IMP (A Summary of the IMP Software)​

Messages​

L'information est transmise d'hôte à hôte dans des paquets appelés messages (messages). Un message est tout flux de pas plus de 8080 bits, avec son en-tête. L'en-tête est de 16 bits et contient les informations suivantes :

Destination     5 bits
Lien (Link)     8 bits
Trace           1 bit
Réserve (Spare) 2 bits

La destination est le code numérique de l'hôte auquel le message doit être envoyé. Le bit de trace signale aux IMP d'enregistrer des informations d'état sur le message et de renvoyer les informations au NMC (Network Measurement Center, centre de mesure du réseau, c'est-à-dire UCLA). Les bits de réserve ne sont pas utilisés.

Le champ de lien est un dispositif spécial utilisé par les IMP pour limiter certains types de congestion. Ils fonctionnent comme suit. Entre chaque paire d'hôtes, il existe 32 connexions logiques bidirectionnelles complètes (logical full-duplex connections) sur lesquelles les messages peuvent être transmis dans l'une ou l'autre direction. Les IMP imposent la restriction sur ces liens qu'aucun hôte ne peut envoyer deux messages successifs sur le même lien avant que l'IMP de destination n'ait renvoyé un message spécial appelé RFNM (Request for Next Message, demande du message suivant). Cet arrangement limite la congestion qu'un hôte peut causer à un autre si l'hôte émetteur tente d'envoyer trop sur un lien. Nous notons cependant que puisque l'IMP de destination n'a pas assez de capacité pour gérer les 32 liens simultanément, les liens ne remplissent leur fonction que si la surcharge provient d'un ou deux liens. Il est nécessaire que les hôtes coopèrent à cet égard.

Les liens ont les caractéristiques primitives suivantes. Ils fonctionnent toujours et il y en a toujours 32.

Par "fonctionnent toujours", nous entendons que les IMP sont toujours prêts à transmettre un autre message sur eux. Aucune notion de début ou de fin de conversation n'est contenue dans le logiciel IMP. Il n'est donc pas possible d'interroger un IMP sur l'état d'un lien (bien qu'il soit peut-être possible d'interroger un IMP sur l'historique récent d'un lien -- une question tout à fait différente !).

L'autre caractéristique primitive des liens est qu'il y en a toujours 32, qu'ils soient utilisés ou non. Cela signifie que chaque IMP doit maintenir 18 tables, chacune avec 32 entrées, quel que soit le trafic réel.

Malgré les objections à la structure des liens, les liens sont facilement programmés dans les IMP et sont probablement une meilleure alternative aux arrangements plus complexes simplement en raison de leur simplicité.

Transmission IMP et vérification des erreurs (IMP Transmission and Error Checking)​

Après avoir reçu un message d'un hôte, un IMP partitionne le message en un ou plusieurs paquets (packets). Les paquets ne dépassent pas 1010 bits de long et sont l'unité de transmission de données d'IMP à IMP. Une somme de contrôle cyclique (cyclic checksum) de 24 bits est calculée par le matériel de transmission et est ajoutée à un paquet sortant. La somme de contrôle est recalculée par le matériel de réception et est vérifiée par rapport à la somme de contrôle transmise. Les paquets sont réassemblés en messages à l'IMP de destination.

Questions ouvertes sur le logiciel IMP (Open Questions on the IMP Software)​

  1. Un champ de 8 bits est fourni pour la spécification du lien, mais seulement 32 liens sont fournis, pourquoi ?

  2. L'hôte est censé pouvoir envoyer des messages à son IMP. Comment fait-il cela ?

  3. Un hôte, par opposition à son IMP, peut-il contrôler les RFNM ?

  4. Les IMP effectueront-ils une conversion de code ? Comment sera-t-elle contrôlée ?

II. Quelques exigences pour le logiciel hôte-à-hôte (Some Requirements Upon the Host-to-Host Software)​

Utilisation simple (Simple Use)​

Comme pour toute nouvelle installation, il y aura une période d'utilisation très légère jusqu'à ce que la communauté d'utilisateurs expérimente le réseau et commence à en dépendre. L'un de nos objectifs doit être de stimuler l'utilisation immédiate et facile par une large classe d'utilisateurs. Avec cet objectif, il semble naturel de fournir la possibilité d'utiliser n'importe quel hôte distant comme s'il avait été composé depuis un terminal TTY (teletype, télétype). De plus, nous aimerions avoir une certaine capacité à transmettre un fichier d'une manière quelque peu différente de la simulation d'un télétype.

Utilisation approfondie (Deep Use)​

L'un des problèmes inhérents au réseau est le fait que toutes les réponses d'un hôte distant nécessiteront de l'ordre d'une demi-seconde environ, aussi simples soient-elles. Pour l'utilisation du télétype, nous pourrions passer à un arrangement d'écho local semi-duplex, mais cela détruirait une partie de l'utilité du réseau. Les systèmes 940, par exemple, ont un écho très spécialisé.

Lorsque nous envisageons d'utiliser des stations graphiques ou d'autres terminaux sophistiqués sous le contrôle d'un hôte distant, le problème devient plus grave. Nous devons chercher une méthode qui nous permette d'utiliser notre équipement le plus sophistiqué autant que possible comme si nous étions connectés directement à l'ordinateur distant.

Vérification des erreurs (Error Checking)​

Jeff Rulifson de SRI fait valoir que la vérification des erreurs aux interfaces logicielles majeures est toujours une bonne chose. Il souligne une certaine expérience au SRI où cela a permis d'économiser beaucoup de disputes et d'efforts perdus. Pour ces raisons, nous aimerions voir une vérification hôte à hôte. En plus de vérifier l'interface logicielle, cela vérifierait également le matériel de transmission hôte-IMP. (BB&N affirme que le matériel hôte-IMP sera aussi fiable que les registres internes de l'hôte. Nous les croyons, mais nous voulons quand même la vérification des erreurs.)

III. Le logiciel hôte (The Host Software)​

Établissement d'une connexion (Establishment of a Connection)​

La connexion la plus simple que nous puissions imaginer est celle où l'hôte local agit comme s'il était un TTY et a composé l'hôte distant. Après avoir examiné les problèmes d'initiation et de terminaison d'une telle connexion, il a été décidé de réserver le lien 0 pour la communication entre les systèmes d'exploitation hôtes. Les 31 liens restants doivent donc être utilisés comme lignes à composer.

Chaque système d'exploitation hôte doit fournir à ses programmes de niveau utilisateur une primitive (primitive) pour établir une connexion avec un hôte distant et une primitive pour rompre la connexion. Lorsque ces primitives sont invoquées, le système d'exploitation doit sélectionner un lien libre et envoyer un message sur le lien 0 à l'hôte distant demandant une connexion sur le lien sélectionné. Le système d'exploitation de l'hôte distant doit accepter et renvoyer un message d'acceptation sur le lien 0. Dans le cas où les deux hôtes sélectionnent le même lien pour initier une connexion et envoient tous deux des messages de demande à peu près au même moment, un simple schéma de priorité sera invoqué dans lequel l'hôte de priorité inférieure cède et sélectionne un autre lien libre. Un schéma de priorité utilisable consiste simplement à classer les hôtes par leurs numéros d'identification. Notez que les deux hôtes sont conscients que des demandes simultanées ont été faites, mais ils prennent des actions complémentaires : l'hôte de priorité supérieure ignore la demande tandis que l'hôte de priorité inférieure envoie à la fois une acceptation et une autre demande.

La connexion ainsi établie est une connexion de type TTY dans l'état pré-connexion. Cela signifie que le système d'exploitation de l'hôte distant traitera initialement le lien comme si un TTY venait d'appeler. L'hôte distant générera les mêmes échos, attendra la même séquence de connexion et recherchera les mêmes caractères d'interruption.

Transmission de gros volumes (High Volume Transmission)​

Les télétypes agissant comme terminaux ont deux inconvénients particuliers lorsque nous envisageons la transmission d'un gros fichier. Le premier est que certains caractères sont des caractères d'interruption spéciaux. Le second est que des techniques de mise en mémoire tampon spéciales sont souvent employées, et celles-ci ne conviennent qu'à une transmission à faible vitesse caractère par caractère.

Nous définissons donc une autre classe de connexion à utiliser pour la transmission de fichiers ou d'autres grands volumes de données. Pour initier cette classe de lien, les programmes de niveau utilisateur aux deux extrémités d'un lien de type TTY établi doivent demander l'établissement d'une connexion de type fichier parallèle au lien de type TTY. Le schéma de priorité entre à nouveau en jeu, car l'hôte de priorité supérieure envoie un message sur le lien 0 tandis que l'hôte de priorité inférieure l'attend. Les programmes de niveau utilisateur ne sont bien sûr pas concernés par cela. La sélection du lien libre est effectuée par l'hôte de priorité supérieure.

Les liens de type fichier se distinguent par le fait qu'aucune recherche de caractères d'interruption n'a lieu et que des techniques de mise en mémoire tampon appropriées pour des débits de données plus élevés sont utilisées.

Un résumé des primitives (A Summary of Primitives)​

Chaque système d'exploitation hôte doit fournir au moins les primitives suivantes à ses utilisateurs. Cette liste est connue pour être nécessaire mais non suffisante.

a) Initier une connexion de type TTY avec l'hôte x.

b) Terminer la connexion.

c) Envoyer/Recevoir des caractères sur une connexion de type TTY.

d) Initier une connexion de type fichier parallèle à une connexion de type TTY.

e) Terminer la connexion de type fichier.

f) Envoyer/Recevoir sur une connexion de type fichier.

Vérification des erreurs​

Nous proposons que chaque message porte un numéro de message, un compteur de bits et une somme de contrôle dans son corps, qui est transparent pour l'IMP. Pour une somme de contrôle, nous suggérons une somme de report de bout en bout (end-around-carry sum) de 16 bits calculée sur 1152 bits puis décalée circulairement vers la droite d'un bit. Le décalage circulaire droit tous les 1152 bits est conçu pour détecter les erreurs de réassemblage des messages par les IMP.

Interaction plus étroite (Closer Interaction)​

Les primitives décrites ci-dessus suggèrent comment un utilisateur peut faire une utilisation simple d'une installation distante. Elles ne donnent aucune indication sur la façon dont une utilisation beaucoup plus complexe du réseau doit être effectuée. Plus précisément, nous sommes préoccupés par le fait qu'à certains sites, beaucoup de travail a été consacré à rendre l'ordinateur très réactif à une console sophistiquée. Les consoles de Culler à UCSB et celles d'Englebart au SRI sont au moins deux exemples. Il est clair que des retards d'une demi-seconde environ pour des réponses triviales de type écho dégradent l'interaction au point de rendre la sophistication de la console non pertinente.

Nous croyons que la plupart des interactions avec la console peuvent être divisées en deux parties, une partie essentiellement locale, immédiate et triviale et une partie distante, plus longue et significative. Comme exemple simple, considérons un utilisateur à une console composée d'un clavier et d'un écran d'affichage rafraîchissant. Le programme dans lequel l'utilisateur tape accumule une chaîne de caractères jusqu'à ce qu'un retour chariot soit rencontré, puis il traite la chaîne. Pendant que les caractères sont tapés, il affiche les caractères sur l'écran. Lorsqu'un caractère d'effacement (rubout) est tapé, il supprime le caractère non-effacement précédent. Si l'utilisateur tape H E L L O <- <- P <CR> où <- est l'effacement et <CR> est le retour chariot, il a effectué neuf frappes. Si chacune de ces frappes entraîne l'envoi d'un message qui à son tour invoque des instructions à notre station d'affichage, nous nous ennuierons rapidement.

Une meilleure solution serait d'avoir la partie frontale du programme distant -- c'est-à-dire la partie qui recherche <- et <CR> -- résidente dans notre ordinateur. Dans ce cas, un seul message de cinq caractères serait envoyé, c'est-à-dire H E L P <CR>, et l'écran serait géré localement.

Nous proposons de mettre en œuvre cette solution en créant un langage pour le contrôle de la console. Ce langage, actuellement nommé DEL, serait utilisé par les concepteurs de sous-systèmes pour spécifier quels composants sont nécessaires dans un terminal et comment le terminal doit répondre aux entrées de son clavier, Lincoln Wand, etc. Ensuite, dans le cadre du protocole initial, l'hôte distant enverrait à l'hôte local le texte en langage source du programme qui contrôle la console. Ce programme aurait été écrit par le concepteur du sous-système en DEL, mais sera compilé localement.

Les spécifications de DEL sont en discussion. Les diagrammes suivants montrent la séquence d'actions.

         /                                                      \
        |     +-----------+                    +-----------+    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     | terminal  |                    | terminal  |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----+-----+                    +-----+-----+    |
        |           |                                |          |
        |           |                                |          |
        |           |                                |          |
        |     +-----+-----+                    +-----------+    |
        |     |     |     | Request connection |     |     |    |
   UCLA {     |     |     | -> over link 25    |     |     |    } SRI
        |     |   +-+-+   |  +-+          +-+  |   +-+-+   |    |
        |     |   | OS|---+-=|I|----------|I|=-+---| OS|   |    |
        |     |   +-+-+   |  +-+          +-+  |   +---+   |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----------+                    +-----------+    |
        |      HOST: UCLA                        HOST: SRI      |
         \                                                     /
         /                                                      \
        |     +-----------+                    +-----------+    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     | terminal  |                    | terminal  |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----+-----+                    +-----+-----+    |
        |           |                                |          |
        |           |                                |          |
        |           |                                |          |
        |     +-----+-----+ "Please send front"+-----------+    |
        |     |     |     | end control"       |     |     |    |
   UCLA {     |     |     |        ->          |     |     |    } SRI ___
        |     |   +-+-+   |  +-+          +-+  |  +--+---+ |    |    /   |
        |     |   | OS|---+-=|I|----------|I|=-+--|OS|NLS| +----+---|    |
        |     |   +-+-+   |  +-+          +-+  |  +------+ |    |   |___/
        |     |           |       DEL prog.    |           |    |   |    |
        |     |           |        <-          |           |    |   |____|
        |     +-----------+                    +-----------+    |
        |      HOST: UCLA                        HOST:SRI       |
         \                                                     /

C. Après réception et compilation du programme DEL (After Receipt and Compilation of the DEL program)​

         /                                                     \
        |     +-----------+                    +-----------+    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     | terminal  |                    | terminal  |    |
        |     |           |                    |           |    |
        |     |           |                    |           |    |
        |     +-----+-----+                    +-----+-----+    |
        |           |Trivial                         |          |
        |           |Responses                       |          |
        |           |                                |          |
        |     +-----+------+                    +-----------+   |
        |     |     |      |                    |     |     |   |
   UCLA {     |     |      |  Major Responses   |     |     |   } SRI ___
        |     |  +--+--+   |  +-+          +-+  |  +--+---+ |   |    /   |
        |     |  |DEL  |---+-=|I|----------|I|=-+--|OS|NLS| +---+---|    |
        |     |  |front|   |  +-+          +-+  |  +------+ |   |   |___/
        |     |  | end |   |                    |           |   |   |    |
        |     |  |prog.|   |                    |           |   |   |____|
        |     |  +-----+   |                    |           |   |
        |     |  | OS  |   |                    |           |   |
        |     |  +-----+   |                    |           |   |
        |     |            |                    |           |   |
        |     +------------+                    +-----------+   |
        |      HOST: UCLA                         HOST: SRI     |
         \                                                     /

Questions ouvertes (Open Questions)​

  1. Si les IMP effectuent une conversion de code, la somme de contrôle ne sera pas correcte.

  2. La procédure pour demander la partie frontale DEL n'est pas encore spécifiée.

IV. Expériences initiales (Initial Experiments)​

Expérience un (Experiment One)​

SRI modifie actuellement son système de récupération en ligne qui sera le composant logiciel majeur du centre de documentation du réseau afin qu'il puisse être exploité avec des télétypes modèle 35. Le contrôle des télétypes sera écrit en DEL. Tous les sites écriront des compilateurs DEL et utiliseront NLS via le programme DEL.

Expérience deux (Experiment Two)​

SRI écrira une partie frontale DEL pour NLS complet, graphiques inclus. UCLA et UTAH utiliseront NLS avec graphiques.

Note : Ce RFC a été mis sous forme lisible par machine pour être entré dans les archives RFC en ligne par Celeste Anderson en mars 1997.

Ressources connexes​

  • Texte officiel : https://www.rfc-editor.org/rfc/rfc1.txt
  • Page officielle : https://datatracker.ietf.org/doc/html/rfc1

Signification historique​

RFC 1 est le premier document RFC de l'histoire d'Internet, marquant le début de l'ARPANET et de la tradition moderne de documentation des protocoles Internet. Écrit par le jeune étudiant diplômé Steve Crocker, il a humblement appelé ces documents « Demande de commentaires (Request for Comments) », un nom qui persiste encore aujourd'hui. Ce document incarne l'esprit de collaboration et l'attitude ouverte des pionniers d'Internet.

Dernière mise à jour le