Résumé

  • RFC 1498 distinguait quatre objets nommables : les services ou utilisateurs, les nœuds, les points d’attachement au réseau et les chemins.
  • Trois liaisons successives reliaient ces objets. Un même serveur pouvait réaliser mécaniquement les deux premières, sans rendre leurs responsabilités identiques.
  • Déplacer un service dans une table ne le renommait pas. Une adresse ou une route restait l’observation d’une liaison courante, non une preuve d’identité, d’autorité ou de résultat.

La réponse qui arrivait trop vite

Un client interroge un serveur de noms avec le nom d’un service. Il reçoit une liste de points d’attachement au réseau. Rien, dans l’interface, ne montre un nœud intermédiaire. On pourrait conclure que le nom du service a été « transformé en adresses » en une seule opération.

RFC 1498 invite à résister à cette conclusion. Le serveur a pu combiner deux travaux : déterminer quels nœuds exécutent le service, puis déterminer par quels points ces nœuds sont attachés. Le routage accomplira encore une troisième liaison, du point du demandeur vers l’un des points rendus. Le fait que l’implémentation masque deux frontières ne les abolit pas.

Ce texte de Jerome Saltzer fut publié comme RFC informative en août 1993, après une première parution en 1982. Il ne proposait pas une nouvelle autorité de nommage. Il apportait une grammaire pour éviter qu’un résultat mécanique ne reçoive plus de sens qu’il n’en possède.

Commencer par les objets

La formule classique disait qu’un nom indique ce que l’on veut, une adresse où cela se trouve et une route comment y parvenir. Saltzer la jugeait utile mais insuffisante. Avant de classer les mots, il fallait classer les choses.

Le premier type réunit services et utilisateurs : fonctions proposées et clients qui les emploient. Le deuxième est le nœud, ordinateur capable d’exécuter un service ou un programme. Le troisième est le point d’attachement, port ou lieu logique par lequel un nœud rejoint le réseau. Le quatrième est le chemin, composé de liaisons et de nœuds de transfert entre points d’attachement.

Dans de nombreuses conversations, « adresse » nomme le troisième objet. Mais la forme ne tranche pas la sémantique. Une chaîne lisible peut désigner un port ; un identifiant binaire peut désigner un nœud ; un objet peut porter plusieurs noms. La bonne question est double : quel objet cette valeur désigne-t-elle, et dans quel contexte sa liaison est-elle conservée ?

Cette discipline empêche une erreur fréquente : croire qu’un nom imprimable est naturellement supérieur dans la hiérarchie, tandis qu’un nombre binaire serait naturellement une localisation. Le support n’attribue pas la fonction.

Trois changements indépendants

Le modèle rend le mouvement explicite. Un service peut passer d’un nœud à un autre sans perdre son identité. Un nœud peut changer de point d’attachement sans devenir un autre nœud. Le chemin entre deux points peut changer sans renommer les extrémités.

Atteindre un service demande donc, au moins conceptuellement, trois décisions : choisir un nœud qui l’exécute, choisir un point qui atteint ce nœud, puis choisir un chemin vers ce point. RFC 1498 les appelle résolution du nom de service, localisation du nom de nœud et service de route.

Chaque étape peut produire plusieurs candidats. Un service répliqué offre plusieurs nœuds ; un nœud multiraccordé offre plusieurs points ; le réseau offre plusieurs chemins. Les choix interagissent : un meilleur chemin peut conduire à préférer un autre nœud. La table peut ne livrer qu’une liaison partielle et laisser la décision finale au client, hors des services de liaison.

Une capture d’écran contenant une seule adresse perd alors des informations décisives : la liste initiale, l’algorithme de sélection, l’heure, l’état de topologie et le résultat applicatif.

La table DIALOG ne pouvait pas rebaptiser

RFC 1498 prend l’exemple d’une ligne indiquant que le service Lockheed DIALOG fonctionne sur le nœud 5. Trois associations se cachent dans la phrase. Le nom DIALOG demeure attaché à un service particulier. Le nom « 5 » demeure attaché à un nœud particulier. Seule la relation actuelle entre ce service et ce nœud est placée dans la table modifiable.

Remplacer 5 par 6 déplace le service. Cela ne donne pas un nouveau nom à DIALOG et ne transforme pas les nœuds. Un véritable changement de nom toucherait aussi les programmes, la documentation, les notes des utilisateurs et les supports publics. La table exprime une relation prévue pour changer ; elle n’est pas le registre universel de toute identité concernée.

La différence est aussi institutionnelle. L’administrateur de cette table dispose du pouvoir opérationnel d’orienter les requêtes vers un nœud. Ce pouvoir n’équivaut pas automatiquement au droit de redéfinir le service, son propriétaire ou les effets juridiques d’une utilisation.

Ethernet : l’économie d’une table et son prix

Dans l’exemple Ethernet, un identifiant de 48 bits peut être lu à la fois comme nom du nœud et comme nom de son point d’attachement. Cette liaison permanente apporte de vrais bénéfices : déplacement physique sans mise à jour des enregistrements, disparition d’un niveau de table, simplification de certains chemins alternatifs.

Mais si un nœud possède deux interfaces indépendamment adressables sur le même Ethernet, deux identifiants risquent de le faire apparaître comme deux nœuds. Employer le même identifiant évite cette apparence mais empêche de viser une interface précise. La fusion économise une liaison dynamique en échange d’une perte de distinction.

L’ARPANET NCP illustrait un autre piège. Des mnémoniques lisibles semblaient nommer des machines ou des services alors qu’ils nommaient des points d’attachement. Quand le même service de courrier était disponible ailleurs, l’utilisateur devait parfois demander ce qui ressemblait à un autre service. La redondance existait dans l’exécution, pas dans le niveau nommé par le mnémonique.

Le chemin n’était pas le reçu

Dans l’interprétation large de Saltzer, l’adresse d’un service peut être le nom d’un nœud qui l’exécute ; l’adresse du nœud, le nom d’un point d’attachement ; l’adresse du point, le nom d’un chemin. Une route vers un service doit encore identifier l’activité ou la socket appropriée dans la machine.

Même cette route complète ne prouve pas la livraison. Elle n’authentifie ni le service ni l’opérateur, ne garantit pas que la socket écoute, ne montre pas la réponse et n’autorise aucun effet extérieur. RFC 1498 précise que les questions de sécurité ne sont pas traitées.

Les textes ultérieurs montrent la persistance de cette tension sans modifier rétrospectivement le mémoire. RFC 1958 déconseille les adresses codées en dur et valorise la modularité. RFC 2101 sépare les exigences d’identifiant et de localisateur et qualifie leur fusion dans IPv4 de fait historique contingent. RFC 2956 décrit les difficultés produites par le mélange de l’identité du nœud et de sa localisation.

Les écrits de Heng Lu sur la primauté du code en fonctionnement, la décision future localisée et les couches de réalité donnent à cette lecture une limite claire : un enregistrement de coordination rend une action possible, mais ne devient ni l’objet, ni l’exécution, ni un mandat sur ceux qui opèrent.

Le dossier probant doit conserver le nom et son espace, la requête horodatée, tous les nœuds et points proposés, l’état de route, le candidat choisi, la socket, la session et la réponse de l’application. RFC 1498 ne demandait pas de rendre les réseaux plus bavards. Il demandait que notre raisonnement ne soit pas plus compact que les objets qu’il prétend décrire.

Sources