Résumé

  • La RFC 1080 autorisait une extrémité Telnet à demander l’activation ou la désactivation du contrôle de flux logiciel chez l’autre, mais seulement après un accord DO/WILL.
  • Cette option visait le trajet local entre le processus Telnet utilisateur et son terminal. Elle ne suspendait ni TCP, ni l’application distante, et ne confirmait pas l’état effectif du pilote.
  • L’accord imposait un état initial activé ; la révocation supprimait le droit d’envoyer des commandes et pouvait ramener le client à une valeur locale propre à l’implémentation.

Deux sens pour les mêmes octets

Le clavier du terminal virtuel de la RFC 854 pouvait produire les 128 codes US-ASCII. Un programme distant pouvait donc considérer Control-S et Control-Q comme de vraies entrées, au même titre que les autres caractères.

Le terminal local leur attribuait souvent une seconde fonction. Le contrôle de flux logiciel interceptait XOFF, généralement Control-S, pour arrêter la sortie, puis XON, généralement Control-Q, pour la relancer. Le pilote consommait la frappe. Le serveur ne la voyait jamais.

Le conflit n’opposait pas un bon caractère à un mauvais. Lorsque le tampon ou le lecteur ne suivait plus, l’interception protégeait l’affichage. Dans certains éditeurs, elle supprimait au contraire une commande légitime. Il fallait donc déplacer la décision sans prétendre que le serveur possédait le terminal.

Publiée en novembre 1988, la RFC 1080 a attribué le code 33 à TOGGLE-FLOW-CONTROL. Sa force tient à la petitesse de la délégation.

Une permission avant le réglage

La RFC 855 organisait les options complexes en deux temps. D’abord, les deux processus acceptaient de parler d’un paramètre. Ensuite seulement venait la sous-négociation.

Dans le cas habituel, l’hôte envoyait DO TOGGLE-FLOW-CONTROL. Le client Telnet relié au terminal répondait WILL. Le premier se déclarait prêt à émettre des demandes ; le second acceptait de modifier son contrôle de flux sur commande.

DONT et WONT refusaient cette relation. Ils ne disaient pas si le pilote utilisait déjà XON/XOFF. Ils fermaient seulement la possibilité de le commander par ce protocole. Aucune sous-négociation ON ou OFF n’était licite avant l’échange complet de DO et WILL.

L’ordre empêchait une commande d’inventer elle-même l’autorité qui la rendait valable. Le mécanisme pouvait fonctionner dans les deux directions, mais son usage normal restait asymétrique : l’application distante connaissait son besoin de caractères littéraux ; le client local maîtrisait la sortie vers le terminal.

L’accord fabriquait un point de départ connu

Après l’accord, l’émetteur de DO pouvait envoyer OFF ou ON. Il ne réduisait pas la fenêtre TCP et n’arrêtait pas le calcul distant. Il demandait au processus Telnet utilisateur de changer la façon dont le pilote local traitait la sortie vers l’écran.

La RFC 1080 imposait aussitôt une activation du contrôle de flux chez l’émetteur de WILL. Ce détail évitait un état initial deviné. Une capture pouvait distinguer l’absence d’option, l’instant où l’option venait d’établir un mode activé, puis une éventuelle demande contraire.

En revanche, ON et OFF ne recevaient pas d’accusé attestant l’application par le pilote. Le paquet prouvait une demande autorisée, pas la position d’un registre local, la consommation d’une frappe ou la pause visible de l’écran.

Les codes de sous-négociation inconnus devaient être ignorés. Cette règle préservait l’extension du protocole, mais le silence du récepteur ne pouvait pas devenir une preuve de capacité.

Retirer l’option, c’était rendre la main au client

À tout moment, une extrémité pouvait envoyer DONT ou WONT. Les sous-négociations suivantes devenaient interdites jusqu’à un nouvel accord.

La RFC n’exigeait pas que le dernier mode survive. Après la désactivation de l’option, le contrôle de flux pouvait revenir à une valeur par défaut définie par l’implémentation. Conserver seulement « dernier ordre : OFF » dans un journal créait donc un faux état après une révocation, une reconnexion ou un redémarrage.

Ce retour local est politiquement intéressant. La délégation cessait avec la session de consentement ; elle ne transformait pas la préférence distante en règle permanente du poste. La normalisation fixait l’entrée et la sortie du pouvoir, sans abolir les choix locaux.

Le réseau ne s’arrêtait pas avec l’écran

Le terme « contrôle de flux » invite aux confusions. L’option 33 ne couvrait qu’un segment : les données sortant du processus Telnet utilisateur vers son terminal. Elle ne décrivait ni les fenêtres de réception TCP, ni les retransmissions, ni la congestion.

Le terminal pouvait disposer d’un contrôle matériel utilisant des fils dédiés, donc sans confisquer Control-S ou Control-Q. Le sens terminal-vers-client pouvait suivre une autre politique. L’application distante pouvait continuer à produire des données déjà placées dans des tampons.

Une observation sérieuse doit nommer la direction et le point de mesure. Voir XOFF sur le clavier ne prouve pas que l’octet a traversé Telnet ; voir OFF sur le réseau ne prouve pas que le pilote a libéré le caractère.

Linemode répartissait les autres fonctions

La RFC 1184 a ensuite décrit le traitement local des lignes. Le client pouvait éditer et répercuter les caractères près de l’utilisateur, puis envoyer une ligne complète au serveur. Ce choix réduisait le trafic et améliorait l’usage des chemins à forte latence.

Son masque de mode couvrait l’édition et les signaux. Le contrôle de flux aurait pu sembler voisin, mais le texte renvoyait explicitement à l’option séparée TOGGLE-FLOW-CONTROL. Une nouvelle option ne devait pas redéfinir silencieusement l’automate d’une autre.

Cette séparation aide aussi l’enquête : le clavier produit, le pilote peut consommer, le client peut traduire, le serveur reçoit éventuellement. Aucun point de capture ne possède à lui seul toute cette chaîne.

La RFC 1372 a rendu visible une absence d’accusé

En 1992, la RFC 1372 a remplacé la RFC 1080. Elle a conservé ON et OFF, puis ajouté RESTART-XON et RESTART-ANY. Le premier demandait que seul XON relance la sortie ; le second autorisait tout caractère sauf un nouvel XOFF.

L’état activé restait connu après DO/WILL, mais la règle de reprise commençait dans un état dépendant du système. Le serveur devait donc demander celle qu’il souhaitait.

Le protocole ne pouvait toutefois pas certifier le résultat. Un client incapable de prendre en charge les deux modes pouvait ignorer la demande. Aucun message ne permettait d’en informer le serveur. « Devrait faire tout son possible » exprimait une obligation d’implémentation, pas une télémétrie.

Dans les pilotes courants, XON et XOFF étaient avalés. Avec la reprise sur n’importe quel caractère, la frappe qui relançait la sortie pouvait ensuite être transmise, sauf lorsqu’il s’agissait de XON. Même la reprise n’avait donc pas un effet unique sur les données.

Le port série constituait encore une autre surface

La RFC 2217 a défini plus tard des commandes Telnet pour les ports série. Elle distinguait la configuration du contrôle entrant ou sortant et une suspension de session FLOWCONTROL-SUSPEND qui arrêtait données et commandes jusqu’à RESUME.

Ces mécanismes ne décrivent pas rétroactivement l’option 33. Régler un UART, suspendre une session et décider si un pilote local consomme XOFF sont trois faits différents.

Le registre IANA des options Telnet conserve le code 33, Remote Flow Control, avec la RFC 1372 comme référence. Il atteste une coordination durable, pas une adoption actuelle ni le bon fonctionnement d’un client.

Cinq preuves pour une seule apparence de mode

Il faut conserver séparément :

  1. le consentement DO/WILL pour l’époque de session ;
  2. la demande ON, OFF ou de reprise ;
  3. l’état réellement appliqué dans le client et le pilote ;
  4. le sort d’une frappe précise, consommée ou transmise ;
  5. l’effet observé sur l’affichage et l’application.

La RFC 1080 fournissait les deux premiers éléments et un état initial. Le reste exigeait une observation locale ou de bout en bout.

Son héritage n’est pas la domination distante d’un vieux terminal. C’est une délégation étroite, révocable et liée à une session, qui rendait deux octets utilisables sans cacher l’endroit où leur sens était décidé.

Sources et limites

La RFC 854 fournit le cadre NVT ; la RFC 855 la grammaire du consentement ; la RFC 1080 l’option initiale ; la RFC 1184 le voisinage Linemode ; la RFC 1372 les modes de reprise ; la RFC 2217 les surfaces série et session ; IANA l’enregistrement. Ces sources ne prouvent ni déploiement actuel, ni authentification, ni état de pilote confirmé, ni incident nommé, ni résultat utilisateur mesuré.