Résumé

  • TCPMUX ouvrait une connexion TCP sur le port 1, puis choisissait le service à partir d’un nom. Après une réponse positive, le protocole demandé utilisait cette même connexion.
  • Le dispositif dispensait un protocole privé d’obtenir son propre port officiel, sans supprimer les conventions communes ni les accès déjà utilisés par les anciens clients.
  • Les manuels d’inetd montrent que le répartiteur pouvait répondre positivement à la place du programme. Une sélection acceptée ne prouvait donc ni son bon fonctionnement, ni l’identité du demandeur, ni l’achèvement de son opération.

Une carte des services, pas un annuaire de l’Internet

Un client pouvait demander HELP au serveur TCPMUX. La réponse était une liste de noms, un par ligne, puis la connexion se fermait. Cette petite carte disait ce que la machine proposait de choisir. Elle ne disait pas où trouver les mêmes services ailleurs, ni si chacun fonctionnerait lorsque le client reviendrait avec une véritable demande.

Ce menu situe bien l’ambition de RFC 1078, publié par M. Lottor en novembre 1988. Le TCP Port Service Multiplexer n’était pas une administration mondiale de nouveaux services. C’était une convention pour les demander à une machine : se connecter au port TCP 1, envoyer un nom terminé par retour chariot et saut de ligne, attendre une réponse de sélection.

Les majuscules et minuscules ne distinguaient pas les noms. Une réponse commençant par un signe positif, éventuellement suivie d’une explication, autorisait le début du protocole choisi. Une réponse négative fermait la connexion. Le client ne recevait pas l’adresse d’un autre serveur et n’ouvrait pas un second canal. La conversation continuait sur le transport déjà établi.

Il faut donc entendre « multiplexage » à l’échelle de l’entrée commune. Plusieurs services étaient accessibles par le même rendez-vous, mais une connexion sélectionnait un service. Le texte ne définissait ni identifiants de flux concurrents ni alternance de messages entre plusieurs applications. Ce détail évite de prêter à deux pages de spécification les capacités d’un système beaucoup plus ambitieux.

Ce qu’un numéro commun rendait possible

Pour qu’un client inconnu trouve un service connu, un numéro de contact convenu était précieux. Le document Assigned Numbers de mai 1987, RFC 1010, explicitement cité par RFC 1078, montre cette pratique de coordination. Il recensait les valeurs utilisées et orientait les développeurs vers un interlocuteur chargé des attributions.

Le gain était collectif : deux équipes n’avaient pas à négocier séparément la signification de chaque numéro. Mais créer un nouveau point de contact reconnu au-delà d’un environnement privé impliquait une nouvelle attribution. TCPMUX cherchait à rendre cette étape inutile pour certains protocoles privés, en réutilisant une entrée déjà commune.

RFC 1078 parlait alors des ports bien connus compris entre 0 et 255. Il s’agit d’un repère historique, pas de la totalité des valeurs représentables dans TCP. Lire ce passage comme une pénurie de tous les ports possibles serait une erreur. Les limites administratives d’une plage et la largeur d’un champ de protocole ne décrivent pas la même contrainte.

Le changement proposé était plus modeste : laisser le nom du service, transmis après la connexion, déterminer le programme. Le numéro commun permettait d’atteindre le répartiteur ; la table de la machine fixait la suite. Ce déplacement retirait une décision au calendrier des attributions globales, sans retirer à l’exploitant la responsabilité de son propre service.

La liberté locale avait une clause de compatibilité

Le nouveau chemin ne pouvait pas faire disparaître l’ancien. RFC 1078 imposait aux services disposant déjà de ports distincts de rester disponibles sur ceux-ci. Leur accès par TCPMUX était facultatif. Le dispositif ajoutait un choix pour les clients capables de le comprendre, plutôt qu’une obligation pour tous les autres.

Cette précaution était nécessaire parce que l’ordre de parole changeait. Un ancien client pouvait attendre une bannière de l’application dès l’établissement de TCP. À l’entrée TCPMUX, le serveur attendait d’abord un nom. Changer seulement le numéro de destination ne suffisait donc pas à rendre le client compatible.

Les noms existants conservaient eux aussi une protection. Ceux figurant dans Assigned Numbers devaient garder leur définition. Pour les protocoles privés, la spécification conseillait des noms peu susceptibles de se confondre, par exemple avec un préfixe d’organisation, et envisageait des suffixes de version. Ce conseil réduisait le risque de collision ; il ne vérifiait ni l’existence juridique d’une organisation ni son contrôle d’un domaine.

On trouve ici une séparation utile entre invention et interopérabilité. Un exploitant pouvait expérimenter une nouvelle correspondance entre nom et programme. Il ne pouvait pas en déduire que les clients savaient déjà l’utiliser, ou détourner un nom réservé tout en prétendant conserver sa signification commune. La latitude locale n’effaçait pas les engagements déjà pris envers les autres.

Le signe positif avait parfois un mandataire

Le manuel NetBSD d’inetd donne au mécanisme un visage concret. Le nom demandé est recherché dans la table issue de /etc/inetd.conf. Avec la forme tcpmux/, le serveur invoqué doit émettre la réponse positive. Avec tcpmux/+, le multiplexeur l’émet pour lui. Cette seconde formule permet de raccorder des programmes utilisant l’entrée et la sortie standard sans leur ajouter un préambule spécialisé.

Ce petit service rendu au programme change la valeur du témoignage reçu par le client. Le signe positif peut exprimer une décision du répartiteur, non une réponse élaborée par l’application. Il ne faut donc pas le présenter comme un certificat de disponibilité du programme, encore moins comme une preuve de travail accompli.

La distinction reste nécessaire quand l’application répond elle-même. Elle peut accepter la conversation puis refuser l’utilisateur, rejeter une commande ou échouer pendant l’opération. L’admission au dialogue et son résultat appartiennent à des étapes différentes. Une surveillance qui les fusionne perd précisément l’information permettant de comprendre où le service s’est arrêté.

La source du manuel FreeBSD d’inetd précise une autre séparation : il faut activer le multiplexeur lui-même, en plus des services individuels. Définir le programme ne crée donc pas à lui seul une entrée accessible. Le manuel décrit aussi la transmission de la connexion au programme par ses descripteurs d’entrée et de sortie.

Ces documents attestent un chemin d’implémentation et des choix de configuration. Ils ne mesurent pas le nombre de déploiements. Leurs indications suffisent néanmoins à attribuer les rôles : le registre coordonne le point de rendez-vous, l’exploitant configure la correspondance locale, le programme interprète les données qui suivent. Aucun de ces acteurs n’accomplit automatiquement le travail des deux autres.

Une idée conservée sans légende de victoire

Les catégories de ports ont évolué. RFC 6335, en 2011, distingue les ports système de 0 à 1023, les ports utilisateur de 1024 à 49151 et les ports dynamiques de 49152 à 65535. Il permet également d’enregistrer un nom de service sans numéro fixe. Le couple nom-numéro n’a donc pas à rester indissociable.

RFC 7605, publié en 2015, traite de l’économie des attributions et du recours à des informations internes au protocole pour distinguer versions ou usages. Il fournit un contexte architectural ultérieur, pas la preuve d’une filiation directe avec TCPMUX. La ressemblance des problèmes ne suffit pas à écrire une chaîne d’influence.

Le registre IANA des services et ports conserve tcpmux au port 1. Il comporte des lignes TCP et UDP ; cette symétrie d’enregistrement ne doit pas faire inventer une conversation UDP à un texte qui spécifie TCP. Une ligne administrative ne complète pas les règles absentes d’un protocole.

Il serait tout aussi imprudent de transformer la persistance du numéro ou du manuel en statistique d’usage. Les sources réunies expliquent ce que le mécanisme permet et où ses obligations commencent. Elles ne démontrent ni un triomphe commercial ni une cause unique d’abandon.

Son intérêt historique est ailleurs. TCPMUX proposait de rendre commun juste assez de langage pour demander un service, puis de laisser l’exploitant décider quel programme pouvait répondre. Cette retenue ne supprimait ni les conventions ni la responsabilité. Elle les plaçait à des endroits que l’on pouvait enfin distinguer dans la conversation.