Aller au contenu principal

Introduction

(Les opinions exposées ici sont à la fois les miennes et celles qui, à mon sens, représentent un consensus du Network Working Group au Project MAC. Les pronoms « je » et « nous » servent à distinguer les unes des autres.)

Les 21 et 23 avril, Thomas P. Skinner et moi-même avons eu des conversations téléphoniques avec Steve Crocker, à UCLA, au sujet du protocole réseau, et plus précisément de notre proposition dans le NWG/RFC 46. Les points suivants ont été discutés. (J'espère que Steve me pardonnera si je le paraphrase inexactement.)

  1. Steve a déclaré qu'à son avis le besoin d'une reconnexion dynamique serait reconnu plus tard par les participants du réseau. Toutefois, faute de consensus, elle ne sera pas incluse dans la mise en œuvre initiale. (Nous, au Project MAC, sommes favorables à cette approche consistant à ne pas l'inclure au départ.)

  2. Steve a soutenu la mise en œuvre de la commande réseau INT décrite dans le NWG/RFC 46.

Cette commande permet à un processus qui a accepté de recevoir des interruptions sur une connexion socket d'être interrompu de façon fiable par le processus situé à l'autre extrémité. L'interruption amène un processus à suspendre son exécution en cours et à exécuter une procédure qu'il a désignée comme gestionnaire d'INT. (Le NCP ne spécifie pas le gestionnaire d'INT. C'est le rôle des protocoles de niveau supérieur.)

La commande INT est conçue spécialement pour être utilisée par un protocole de commande et de communication utilisateur (UCC) de troisième niveau afin de mettre en œuvre un signal « quit ». Dans un tel protocole, le demandeur et le processus créé conviennent qu'un INT lié à une connexion socket déterminée et transmis par la liaison de contrôle du NCP au processus créé constitue le signal « quit » normalisé. Le processus créé fournit un gestionnaire d'INT qui met en œuvre cette fonction « quit ». (Cela n'empêche pas d'autres protocoles de troisième niveau d'interpréter INT différemment.)

Bien que de nombreux systèmes mettent en œuvre le « quit » sous forme de caractère de commande dans le flux d'entrée du télétype, des systèmes tels que CTSS, Multics et d'autres le mettent en œuvre sous forme d'un espacement de 200 ms sur la ligne. Nous, au MAC, estimons que la première méthode est une mise en œuvre indésirable dans le réseau (la seconde étant impossible). J'ai exposé plusieurs raisons à cela (et je crois que Steve était d'accord).

(a) La liaison sur laquelle le caractère de quit doit être transmis peut être bloquée.

(b) Bien que l'interruption soit mise en œuvre le plus efficacement au sein du NCP, il n'est pas souhaitable que le NCP impose une structure particulière aux données transmises. (Voir la discussion ci-dessous.) Cela serait nécessaire si le NCP devait parcourir un flux de données à la recherche d'un caractère de commande.

(c) Le parcours du flux d'entrée réduit fortement l'efficacité du NCP dans un sous-système où la vitesse est déterminante pour un fonctionnement efficace.

Steve a fait remarquer que la mise en œuvre d'INT comme « quit » ne devrait pas nécessairement empêcher un HOST d'interpréter aussi comme « quit » un caractère de commande présent dans le flux d'entrée.

  1. Steve est opposé à la fois à l'inclusion d'une étiquette d'instance dans l'identifiant de socket et à la réservation d'un champ nul dans l'identifiant aux fins d'une définition future. Il a cité plusieurs raisons :

(a) Les processus multiples d'un même utilisateur doivent être indistinguables pour un processus étranger. (Je suis d'accord dans certains cas, lorsque des processus sont coordonnés dans une action commune. Mais qu'en est-il lorsque deux processus du même utilisateur veulent utiliser le réseau indépendamment l'un de l'autre ?)

(b) Un processus qui souhaite se connecter à l'un des processus d'un utilisateur étranger ne connaît pas l'étiquette d'instance du processus particulier qu'il veut joindre, et il ne peut pas la découvrir facilement.

(c) Si une étiquette d'instance s'avérait souhaitable plus tard, on pourrait l'ajouter avec quelque difficulté. (Je soutiens qu'une chose aussi fondamentale que la longueur d'un identifiant de socket se révèle très résistante au changement.)

Tom a déclaré que l'on pourrait peut-être réserver les trois bits de poids faible du code utilisateur pour une interprétation ultérieure comme étiquette d'instance. Il ne pense pas qu'un champ séparé soit d'une grande importance.

Les arguments de Steve semblent avoir du mérite. La suggestion de Tom est peut-être la voie à suivre. Je suis actuellement indécis sur cette question.

  1. Nous semblons tous (Steve et le MAC) convenir qu'au niveau du NCP aucune structure particulière ne doit être imposée aux données transmises. Pour un NCP, toutes les données à transmettre sont des chaînes de bits de longueur arbitraire. Un heureux résultat est que la difficile question des jeux de caractères n'a pas à être tranchée à ce niveau de protocole. Inclure une spécification de jeu de caractères au niveau du NCP retarderait l'accord sur le protocole et rendrait ce jeu de caractères plus résistant au changement. (S'il doit y avoir un jeu de caractères normalisé, nous préférons l'ASCII. Après tout, c'est le standard préféré de notre organisme de tutelle.)

Nous convenons également avec Steve qu'il ne doit pas y avoir d'écho facultatif des messages au niveau du protocole NCP. (C'est aussi la position des gens du SDC dans le RFC 44.)

  1. Shoshani, Long et Landsberg déclarent aussi (RFC 33) qu'ils préfèrent aligner les messages pour qu'ils se terminent sur une frontière de mot plutôt que de recourir au double remplissage. Steve est d'accord avec nous pour ne pas aimer le double remplissage.

  2. Dans notre proposition (RFC 46), nous suggérons que les RFC ne soient mis en file d'attente que pour les sockets ouverts, et que les RFC destinés à des sockets inactifs ou connectés soient automatiquement rejetés au moyen de la commande CLS. Steve propose que les RFC destinés à ces sockets soient brièvement mis en file d'attente. Si le socket reste dans un état inacceptable pendant un intervalle déterminé après l'arrivée du RFC, celui-ci est rejeté. Ce schéma permet de mettre en œuvre certains types d'interactions de commandes réseau impliquant des situations de concurrence critique. Un tel schéma de mise en file d'attente limitée ne me paraît pas déraisonnable.

  3. Steve, Tom et moi avons discuté des stratégies pour un protocole de commande et de communication utilisateur (UCC). Steve a dit qu'il n'aimait pas notre stratégie UCC (RFC 46) parce qu'elle exige de maintenir deux connexions full-duplex vers le processus demandeur et de basculer entre elles.

Steve a avancé une proposition alternative : un processus qui souhaite créer un processus utilisateur sur un HOST étranger émet des RFC vers les sockets 0 et 1 appartenant à l'utilisateur dont il veut créer le processus. Si ces sockets sont inactifs, le NCP dirige automatiquement ces requêtes vers le processus de connexion (logger) du HOST étranger. Le logger accepte la connexion et accomplit le rituel de connexion. En cas de succès, le logger crée un processus utilisateur et libère les sockets usurpés afin que le processus créé puisse les utiliser pour communiquer avec le processus demandeur. (Je note que cela n'utilise pas la reconnexion au niveau du réseau, puisque le logger utilise des sockets appartenant à l'utilisateur final. En revanche, cela implique une reconnexion interne.)

Tom et moi nous y sommes opposés parce que cela introduit le protocole UCC au niveau du NCP. (Le NCP doit diriger tous les RFC adressés aux sockets 0 et 1 inactifs vers un processus de connexion.) J'ai fait une suggestion rapide : peut-être pourrions-nous combiner nos deux propositions de sorte que le demandeur émette un RFC de « signalisation » vers un socket « signal » du processus UCC. L'UCC rejette le RFC mais se souvient de l'appelant. Il tente ensuite de connecter deux sockets du processus à créer aux sockets du demandeur et conduit le rituel de connexion à travers eux. Steve a aimé cette idée et m'a suggéré de la rédiger.

Après la conversation, j'ai songé à plusieurs inconvénients de cette stratégie UCC :

(a) Si les sockets de contrôle d'un processus créé sont limités à 0 et 1, il est possible qu'un utilisateur légitime ne puisse pas communiquer avec un UCC étranger parce que l'UCC utilise déjà ces sockets pour communiquer avec un imposteur. Le logger découvrira la chose et coupera l'imposteur, mais il s'agit d'une faille de sécurité aggravante. Un processus malveillant pourrait émettre simultanément de multiples requêtes pour occuper les sockets et empêcher l'accès d'un utilisateur légitime. Une meilleure solution consiste à permettre à n'importe quelle paire de sockets du processus utilisateur potentiel de servir de chemin de contrôle. Cela permet à l'UCC de mener des interrogations simultanées de demandeurs concurrents.

(b) Un inconvénient de l'UCC de Crocker comme de l'UCC combinée est que l'utilisateur à connecter est désigné en fournissant un socket appartenant à un utilisateur particulier. Le logger doit désormais faire la vérification supplémentaire que l'utilisateur auquel il donne accès appartient bien à la paire de sockets sur laquelle il dialogue. Cela semble l'inverse du processus préféré : identifier un utilisateur, puis déterminer le code utilisateur de ses identifiants de socket.

(c) L'utilisateur peut ne pas connaître le code utilisateur du socket de l'utilisateur qu'il souhaite connecter sur le HOST étranger. (Après tout, il n'y a pas de raison fondamentale pour que les processus demandeur et créé aient le même code utilisateur, dès lors que le demandeur satisfait le logger étranger.)

(d) Dans la stratégie combinée, le demandeur n'a aucun moyen de préciser quel code utilisateur de socket il souhaite. La seule hypothèse que l'UCC puisse faire est que le processus demandeur souhaite connecter un processus ayant le même code utilisateur de socket que lui-même. (Cela peut sembler peu important, mais j'envisage un schéma dans lequel un processus local existe pour permettre aux consoles rattachées au HOST local de se connecter à un HOST étranger sans être connectées localement.)

(e) L'idée de permettre à un processus de se faire passer, dans le réseau, pour un autre processus (même avec les meilleures intentions) en utilisant son code utilisateur de socket introduit une faille de sécurité potentiellement dangereuse. Je pense qu'il devrait être une loi fondamentale du protocole qu'aucun processus, quel qu'il soit, ne demande ou n'accepte de connexions, ni ne transmette ou ne reçoive de données, sur un socket dont le code utilisateur n'est pas le sien. Cela ne s'applique pas à un processus NCP qui a la responsabilité d'une telle transmission, et n'empêche pas non plus un processus privilégié de fermer ou de rejeter des connexions entre un processus étranger et un autre processus local.

Je pense toujours que la proposition UCC que nous avons avancée dans le RFC 46 est un bon schéma réalisable. Elle n'exige pas de reconnexion de socket (ni explicitement dans tout le réseau, ni implicitement au sein d'un NCP), et aucune des objections soulevées ci-dessus ne s'y applique. Le seul inconvénient particulier que j'y vois est qu'elle oblige le processus demandeur à maintenir deux connexions full-duplex et à basculer entre elles. Je n'y vois pas un obstacle sérieux. Je souhaiterais en particulier les commentaires des participants du réseau sur ce point.

Heureusement, l'UCC est un protocole de troisième niveau. Le NCP de deuxième niveau peut être spécifié avant que nous parvenions à un accord final sur un UCC, à condition que le NCP permette la mise en œuvre d'un UCC réalisable.

Steve a exprimé l'idée qu'il n'est pas nécessaire qu'il existe un UCC normalisé initial, et qu'il pourrait y avoir plusieurs UCC. Nous, au MAC, ne sommes pas d'accord. Si nous devons tous communiquer entre nous, et non entre des sous-ensembles limités de HOST du réseau, il doit exister un UCC normalisé initial que tout le monde met en œuvre. (Steve a bien sûr raison de dire que d'autres UCC expérimentaux peuvent également être mis en œuvre.)

Il est théoriquement possible que chaque HOST fournisse plusieurs ensembles de logiciels pour permettre à un processus demandeur de communiquer avec les loggers des HOST mettant en œuvre différents UCC. Je ne pense pas que cela fonctionnera ainsi en pratique. Chaque HOST mettra en œuvre le protocole UCC qui lui convient le mieux et ne fournira qu'un seul ensemble de logiciels, de sorte qu'un processus demandeur ne pourra communiquer qu'avec les HOST mettant en œuvre des UCC similaires.

Je ne pense pas qu'il y ait beaucoup d'enthousiasme au Project MAC pour mettre en œuvre un UCC non normalisé simplement afin de pouvoir dialoguer entre nous. Nous voulons mettre en œuvre un UCC unique pris en charge dans toutes les installations, afin de pouvoir nous connecter à tous les HOST au moyen de ce protocole, et que les utilisateurs de tous les HOST étrangers puissent se connecter chez nous.

Note: Ce RFC a été mis sous forme lisible par machine pour son entrée dans les archives RFC en ligne par Altair Petrofsky 7/97.