Concepts de conception

Les ordinateurs qui participent au réseau se ressemblent sur deux points importants : chacun prend en charge des recherches indépendantes du réseau, et chacun est soumis à la discipline d'un système à temps partagé. Ces faits ont contribué à la philosophie de conception suivante.

Premièrement, comme les ordinateurs du réseau ont des finalités indépendantes, il est nécessaire de préserver un contrôle administratif décentralisé des différents ordinateurs. Étant donné que tous les superviseurs de temps partagé possèdent des mécanismes élaborés et précis de comptabilité et d'allocation des ressources, nous avons organisé les choses de manière à ce que ces mécanismes contrôlent la charge due au réseau de la même façon qu'ils contrôlent la charge générée localement.

Deuxièmement, comme tous les ordinateurs fonctionnent sous des disciplines de temps partagé, il a semblé souhaitable de faciliter les mécanismes interactifs de base.

Troisièmement, comme ce réseau est utilisé par des programmeurs expérimentés, il était impératif d'offrir la plus grande latitude dans l'utilisation du réseau. Les restrictions concernant les jeux de caractères, les langages de programmation, etc. n'auraient pas été tolérées et nous avons évité de telles restrictions.

Quatrièmement, là encore parce que le réseau est utilisé par des programmeurs expérimentés, il a été jugé nécessaire de laisser la conception ouverte. Nous nous attendons à ce que des conventions apparaissent de temps à autre au fur et à mesure que l'expérience s'acquiert, mais nous nous sommes interdits de les imposer arbitrairement.

Cinquièmement, afin de rendre la participation au réseau confortable, ou dans certains cas possible, l'interface logicielle vers le réseau ne devrait exiger qu'une intervention minimale sur le système d'exploitation de l'hôte.

Enfin, nous acceptons l'hypothèse énoncée ci-dessus selon laquelle l'usage du réseau consiste en conversations prolongées plutôt qu'en requêtes ponctuelles.

Ces considérations ont conduit aux notions de connexions, de programme de contrôle du réseau, de liaison de contrôle, de commandes de contrôle, de sockets et de réseaux virtuels.

Une connexion est une extension d'une liaison. Une connexion relie deux processus de sorte que la sortie de l'un est l'entrée de l'autre. Les connexions sont simplex, de sorte que deux connexions sont nécessaires si deux processus doivent converser dans les deux sens.

Les processus d'un hôte communiquent avec le réseau par l'intermédiaire d'un programme de contrôle du réseau (Network Control Program, NCP). Dans la plupart des hôtes, le NCP fera partie de l'exécutif, de sorte que les processus utiliseront des appels système pour communiquer avec lui. La fonction principale du NCP est d'établir des connexions, de rompre des connexions, de commuter des connexions et de contrôler le flux.

Pour accomplir ses tâches, un NCP d'un hôte doit communiquer avec un NCP d'un autre hôte. À cette fin, une liaison particulière entre chaque paire d'hôtes a été désignée comme liaison de contrôle. Les messages reçus sur la liaison de contrôle sont toujours interprétés par le NCP comme une séquence d'une ou plusieurs commandes de contrôle. À titre d'exemple, l'un des types de commandes de contrôle sert à attribuer une liaison et à établir une connexion, tandis qu'un autre type porte la notification qu'une connexion a été terminée. Un aperçu partiel de la syntaxe et de la sémantique des commandes de contrôle est donné dans la section suivante.

Une question majeure est de savoir comment désigner les processus d'un hôte étranger. Chaque hôte possède un schéma de nommage interne, mais ces divers schémas sont souvent incompatibles. Comme il n'est pas pratique d'imposer un schéma commun de nommage des processus internes, un espace de noms intermédiaire a été créé, une portion distincte de cet espace étant attribuée à chaque hôte. Il appartient à chaque hôte de faire correspondre les identifiants internes de ses processus à son espace de noms.

Les éléments de l'espace de noms sont appelés sockets. Une socket forme une extrémité d'une connexion, et une connexion est entièrement spécifiée par une paire de sockets. Une socket est spécifiée par la concaténation de trois nombres :

(a) un numéro d'utilisateur (24 bits)
(b) un numéro de HOST (8 bits)
(c) AEN (8 bits)

Une socket typique est illustrée à la figure 3.

Chaque hôte se voit attribuer toutes les sockets de l'espace de noms dont le champ (b) est égal à son propre identifiant.

Une socket est soit une socket de réception, soit une socket d'émission, et elle est marquée comme telle par le bit de poids faible de l'AEN (0 = réception, 1 = émission). Les sept autres bits de l'AEN fournissent simplement une population appréciable de sockets pour chaque numéro utilisé sur chaque hôte. (AEN signifie "another eight-bit number")

Chaque utilisateur se voit attribuer un numéro d'utilisateur de 24 bits qui l'identifie de façon unique dans tout le réseau. Généralement, il s'agira du numéro de HOST de 8 bits de son hôte d'origine, suivi de 16 bits qui l'identifient de façon unique sur cet hôte. On peut également prévoir qu'un utilisateur ait un numéro d'utilisateur non rattaché à un hôte particulier, arrangement souhaitable pour les utilisateurs mobiles qui pourraient n'avoir aucun hôte d'origine ou plus d'un. Ce numéro d'utilisateur de 24 bits est ensuite utilisé de la manière suivante. Lorsqu'un utilisateur ouvre une session sur un hôte, son numéro d'utilisateur est recherché. Par la suite, chaque processus que l'utilisateur crée est étiqueté avec son numéro d'utilisateur. Lorsque l'utilisateur ouvre une session sur un hôte étranger via le réseau, le même numéro d'utilisateur sert à étiqueter les processus qu'il crée sur cet hôte. L'hôte étranger obtient le numéro d'utilisateur soit en consultant une table au moment de l'ouverture de session, comme le fait l'hôte d'origine, soit en reconnaissant l'identification de l'appelant. L'effet de la propagation du numéro de l'utilisateur est que chaque utilisateur crée son propre réseau virtuel constitué des processus qu'il a créés. Ce réseau virtuel peut s'étendre sur un nombre arbitraire d'hôtes. Il sera donc facile pour un utilisateur de connecter ses processus de manière arbitraire, tout en lui permettant de connecter ses processus à ceux d'autres réseaux virtuels.

La relation entre les sockets et les processus est maintenant descriptible (voir figure 4). Pour chaque numéro d'utilisateur sur chaque hôte, il existe 128 sockets d'émission et 128 sockets de réception. Un processus peut demander au NCP local l'utilisation de l'une quelconque des sockets portant le même numéro d'utilisateur ; la demande est accordée si la socket n'est pas déjà utilisée par ailleurs. L'observation clé ici est qu'une socket demandée par un processus ne peut pas déjà être utilisée, sauf par un autre processus du même réseau virtuel, et un tel processus est contrôlé par le même utilisateur.

Un aspect inhabituel du protocole HOST-HOST est qu'un processus peut commuter son extrémité d'une connexion d'une socket à une autre. La nouvelle socket peut se trouver dans n'importe quel réseau virtuel et sur n'importe quel hôte, et le processus peut déclencher la commutation soit au moment où la connexion est établie, soit plus tard. Les formes les plus générales de commutation impliquent une mise en œuvre assez complexe et ne sont pas pertinentes pour le reste de cet article ; seule une forme limitée sera donc expliquée. Cette forme limitée de commutation prévoit uniquement qu'un processus peut substituer une socket à une autre au moment d'établir une connexion. La nouvelle socket doit avoir le même numéro d'utilisateur et le même numéro de HOST, et la connexion est toujours établie vers le même processus. Cette forme de commutation n'est donc qu'un moyen de réétiqueter une socket, car aucun changement dans le routage des messages n'a lieu. Dans la section suivante, nous documentons les appels système et les commandes de contrôle ; dans la section d'après, nous examinons comment l'ouverture de session pourrait être mise en œuvre.