Résumé

  • La RFC 871 présentait le modèle de référence de l’ARPANET comme la mise en mots de choix déjà éprouvés par son groupe de travail pour faire coopérer des ordinateurs différents.
  • Sa règle la moins décorative était l’équité : une simplification de protocole pouvait bouleverser l’authentification ou la comptabilité d’un autre système d’exploitation.

La proposition avait l’air généreuse : pour éviter de facturer la réception du courrier électronique, dispensons l’expéditeur d’une commande de connexion. Michael A. Padlipsky raconte dans la RFC 871 ce qui a arrêté le geste. Sur certains systèmes d’exploitation, les commandes de connexion déclenchaient aussi l’authentification. Les retirer du parcours de FTP simplifiait la vie d’une machine et abîmait le contrôle d’une autre. La solution décrite conservait la possibilité d’exiger la connexion et utilisait un compte commun, gratuit pour l’arrivée des messages. Une jolie règle venait de rencontrer un ordinateur qui avait déjà ses propres règles.

Padlipsky appelait cela l’équité. Les concepteurs devaient écouter celui qui répondait : « chez moi, votre mécanisme casse quelque chose ». La réponse pesait davantage quand elle venait d’une personne chargée de le faire fonctionner sur un système réel. Le réseau réunissait des hôtes différents ; ses protocoles devaient supporter cette différence au lieu de la masquer dans un dessin. La discussion n’avait rien d’une cérémonie abstraite : elle portait sur un chemin de connexion, une fonction de sécurité et une facture.

En septembre 1982, Padlipsky publia A Perspective on the ARPANET Reference Model. Il expliquait que les membres du Network Working Group avaient bâti une suite de protocoles à partir d’un cadre conceptuel souvent tacite. Entre-temps, le modèle de référence ISO était devenu l’image connue à laquelle on comparait toute architecture. Padlipsky voulait exposer les choix de l’ARPANET dans leur ordre propre, à partir de systèmes et de protocoles déjà utilisés. Son texte reconstruisait une méthode de travail plus ancienne que sa présentation en modèle.

La première question était l’objectif. Il s’agissait de partager les ressources de machines potentiellement hétérogènes. Ouvrir une session à distance pouvait aider, mais les programmes et les données de plusieurs hôtes devaient aussi coopérer. Cela conduisait à la communication entre processus en cours d’exécution. Des connexions logiques permettaient de distinguer ces échanges : un numéro de socket connu indiquait où trouver un service, tandis que d’autres numéros restaient disponibles pour expérimenter. Le numéro avait un sens pour le service, au-delà de son utilité pour aiguiller des bits.

La diversité des terminaux posait un autre problème. Si chaque type d’hôte devait connaître chaque type de terminal, chaque nouveau venu ajoutait des combinaisons à traiter. La représentation commune du terminal virtuel plaçait une forme intermédiaire entre eux. Chaque système traduisait depuis ou vers cette forme partagée. Le transfert de fichiers pouvait tirer parti d’un mécanisme voisin. Au lieu de demander à tous les ordinateurs d’apprendre tous les dialectes de tous les autres, le réseau proposait une langue commune à ses frontières.

Le modèle décrivait ensuite trois larges groupes fonctionnels : interface réseau, communication entre hôtes, applications ou processus. Plusieurs protocoles pouvaient habiter un même groupe. La séparation protégeait les détails internes d’un protocole contre les changements survenus dans un autre. Padlipsky se méfiait d’une lecture où chaque case d’un diagramme imposerait un passage obligatoire à chaque message. Un modèle de référence servait à expliquer comment un ensemble fonctionnait. Une tour de sept étages devient pénible si, pour rejoindre son voisin de palier, on doit descendre jusqu’à la cave avant de remonter.

L’efficacité faisait partie du calcul : temps de processeur, mémoire, conversions inutiles. L’équité y ajoutait la capacité d’intégrer les interprètes de protocole aux systèmes d’exploitation existants. Padlipsky comparait sévèrement sa reconstruction au modèle ISO, et son appréciation restait celle d’un participant au débat. Son point le plus concret tenait pourtant dans le compte de courrier : l’idée de supprimer une étape devait être vérifiée sur les machines qui s’appuyaient sur elle.

La RFC 871 donne ainsi plus qu’un dessin à trois groupes. Elle suit le travail nécessaire pour relier des programmes, préserver une fonction locale importante et réduire le nombre de traductions entre machines. La beauté du modèle venait de sa capacité à faire travailler ensemble des systèmes différents. Le refus d’un système d’exploitation pouvait améliorer la règle commune.