Aller au contenu principal

IV - Protocole de contrôle et de communication utilisateur

Il doit exister un processus qui accepte d'écouter n'importe qui sur le réseau et de créer un processus pour lui après identification convenable. Ce processus est appelé le logger et interagit par l'intermédiaire du NCP via le module de contrôle et de communication utilisateur (UCC) lié au réseau, qui met en œuvre le protocole nécessaire. Hormis un seul cas (la fermeture (CLOSE) des connexions de processus morts), le processus exploitant le module UCC n'a pas de privilèges de réseau particuliers.

Selon le protocole UCC, un processus "demandeur" qui a demandé la création d'un processus "étranger" entretient deux connexions pseudo-téléscripteur full-duplex: l'une vers le logger étranger, et l'autre vers le processus créé. La connexion duplex vers le logger étranger sert à identifier le processus demandeur auprès du logger, et après la connexion à renvoyer au processus demandeur les informations de base concernant la santé du processus créé. La connexion duplex vers le processus créé sert à la communication de contrôle avec celui-ci.

Le maintien de deux connexions full-duplex évite les problèmes de reconnexion, tant lorsque le logger transfère la communication au processus créé que lorsqu'il doit reprendre le contrôle. Cela se fait au prix modeste d'exiger du processus demandeur qu'il commute les communications téléscripteur entre deux ensembles de connexions.

La manière dont la communication est établie est essentiellement la suivante: le processus demandeur réserve d'abord quatre de ses sockets ayant des codes de socket contigus. Ensuite il "signale" l'UCC en spécifiant l'un de ces sockets. À partir de ce "signal", l'UCC sait quel processus appelle, et, de par le protocole, sur quelle paire de sockets du demandeur l'UCC doit communiquer avec le processus demandeur, et quelle paire de sockets du demandeur le processus créé doit utiliser pour ses communications. Ceci est spécifié plus en détail ci-dessous.

Établissement et exploitation d'un processus distant​

L'UCC de chaque HOST garde toujours ouvert (actif et non connecté) un socket d'émission avec numéro d'utilisateur = 0 et instance tag = 0 comme socket "signal", et vérifie périodiquement l'arrivée d'INIT vers ce socket. Les processus qui souhaitent créer un processus sur ce HOST doivent d'abord signaler l'UCC en émettant un INIT vers ce socket.

Le processus demandeur doit disposer de quatre sockets libres ayant des codes de socket contigus: <base_socket> (réception) jusqu'à <base_socket+3> (émission). L'ensemble émission/réception aux numéros élevés sert à la communication téléscripteur avec l'UCC étranger, l'ensemble aux numéros faibles à la communication téléscripteur avec le processus créé.

  1. Le processus "demandeur" appelle LISTEN deux fois pour ouvrir la paire réception/émission <base_socket+2> et <base_socket+3> par laquelle il parlera à l'UCC étranger. Puis il émet un appel INIT "de signalisation" sur <base_socket> vers le socket "signal" de l'UCC. La seule chose que l'UCC fait de cet appel INIT "de signalisation" est de noter le numéro de socket <base_socket> dont il provient. L'UCC refuse immédiatement cette demande afin de garder son socket "signal" ouvert pour d'autres signaux.

  2. Après avoir reçu le REJECT attendu sur son appel INIT initial vers le socket signal de l'UCC, le processus demandeur émet des LISTEN pour <base_socket> et <base_socket+1>. (Le processus créé exécutera INIT sur ces sockets pour établir la communication de contrôle avec le processus demandeur.) Le processus demandeur se bloque ensuite en appelant STATUS <base_socket+2> .

  3. L'UCC exécute INIT d'une paire émission/réception libre vers <base_socket+2> et <base_socket+3> du demandeur, sur lesquels le processus demandeur est vraisemblablement en train d'écouter. Le processus demandeur a appelé STATUS <base_socket+2> avec l'option de blocage après avoir écouté les deux sockets, de sorte que lorsque l'INIT de l'UCC étranger atteint le processus demandeur, STATUS revient avec l'indication INIT. Le processus demandeur vérifie que c'est bien l'UCC qui appelle, puis il exécute ACCEPT de l'appel. Le processus demandeur appelle ensuite STATUS <base_socket+3> et revient lorsque l'INIT de ce socket lui parvient. Il effectue une vérification et un ACCEPT semblables. (Le choix du socket pour lequel le processus demandeur appelle STATUS en premier est arbitraire.) La communication bidirectionnelle est établie lorsque le processus demandeur a accepté (ACCEPT) les deux INIT de l'UCC. Cette connexion est maintenue pendant le rituel de connexion et tout au long de la vie du processus créé. Si le processus demandeur ne répond pas correctement dans un délai limité aux INIT de l'UCC, l'UCC abandonne la tentative de connexion.

  4. Le processus demandeur doit ensuite accomplir le rituel de connexion avec l'UCC. (Le protocole initial pourrait standardiser le rituel de connexion.) Si le logger n'est pas satisfait et souhaite couper le demandeur, le module UCC exécute CLOSE sur <base_socket+2> et <base_socket+3>, peut-être après que le logger a envoyé un message approprié.

  5. S'il est satisfait, le logger crée un processus pour l'utilisateur. L'UCC maintient une communication directe avec le demandeur, mais cette connexion ne sert plus qu'à rapporter les informations de base concernant le processus créé.

  6. La première tâche d'un processus créé est d'établir une double connexion de contrôle pseudo-téléscripteur avec son processus demandeur. Le processus créé exécute INIT de l'une de ses paires émission/réception vers les <base_socket> et <base_socket+1> du demandeur. Si les deux demandes sont acceptées (ACCEPT), le processus créé envoie un message initial sur cette connexion. Il passe ensuite au niveau de commande, où il attend un message de commande téléscripteur sur la connexion. Si le processus créé ne parvient pas à établir une communication duplex avec le processus demandeur, il devrait se détruire. L'UCC soit exécutera CLOSE sur ses propres connexions avec le demandeur, soit prendra des dispositions pour qu'un autre processus soit créé.

  7. Lorsqu'un processus créé est déconnecté, l'UCC utilise une entrée privilégiée vers le NCP pour exécuter CLOSE sur toutes les connexions entre le processus mort et les autres processus, et pour désactiver tous les sockets ouverts du processus mort. L'UCC transmet un message en retour au processus demandeur, puis exécute CLOSE sur les deux connexions entre lui et le processus demandeur.

  8. L'appel INTERRUPT a un sens standard de "quit" lorsqu'il est envoyé d'un processus demandeur à un processus créé par le socket de réception <base_socket> du demandeur. Toute sortie en attente du processus créé est abandonnée, et celui-ci entre au "niveau de commande" où il attend une commande sur la connexion téléscripteur vers le processus demandeur. Le traitement interrompu peut être repris en émettant une commande "start" vers le processus créé. (Notons que la règle concernant les sorties en attente est plus restrictive que celle mise en œuvre par la commande INT du NCP.)

Ce document a été préparé au moyen de la commande "runoff" de MULTICS. Un fichier source composé de texte et de requêtes "runoff" entremêlés a été créé avec l'éditeur de texte "qed". Ce fichier a ensuite été compilé par la commande "runoff" pour produire un exemplaire définitif. La dernière version de ce document existe en ligne dans MULTICS dans le segment

>udd>Multics>Meyer>network_protocol.runoff

(END)

      REQUESTOR                                  FOREIGN
      PROCESS                                    LOGGER
      --------------                             -------------
      a. LISTEN to sockets
      <base_socket+2> and
      <base_socket+3> to be
      connected to foreign logger.

      b. INIT <base_socket>
      to "signal" socket of
      foreign logger.
                =======================================>

                                                c. remember <base_socket>
                                                   and REJECT connection
                                                   to signal socket.

      d. LISTEN to sockets                      e. INIT a logger socket
      <base_socket> and                            pair to the requestor's
      <base_socket_1> to be                       <base_socket+2> and
      connected to the created  process.          <base_socket+3>.
                                                   /
                       <==========================/

      f. ACCEPT connection
      with sockets from
      foreign logger.

                             PERFORM LOGIN RITUAL
                                                CREATED
                                                PROCESS
                                                -------------
                                                g. INIT any socket pair
                                                   to requestor's
                                                   <base_socket> and
                                                   <base_socket+1>
                                                    /
                       <===========================/
      h. ACCEPT connection
      with sockets from created
      process.

Figure 4 : Établissement d'un processus sur un HOST étranger

Note : Ce RFC a été mis sous forme lisible par machine pour être versé aux archives RFC en ligne par Miles McCredie 11/99.