Résumé

  • En mai 1983, Jon Postel et Joyce Reynolds décrivent dans la RFC 860 l’option TELNET TIMING-MARK, numéro 6. Une extrémité demande DO TIMING-MARK; l’autre, si elle accepte, insère WILL TIMING-MARK au bon endroit dans le flot de retour après le passage par ses tampons.
  • L’exemple décisif est celui d’une commande mal écrite suivie de texte tapé en avance. Le serveur peut jeter les caractères qui arrivent jusqu’à la marque renvoyée, puis reprendre avec ce que l’utilisateur a saisi après avoir vu le signe d’erreur. Celui qui demande la marque décide lui-même de ce qu’il jette.

Imaginez un utilisateur qui tape plus vite que le temps de réponse du serveur. Une première commande contient une faute; la deuxième est déjà en route. Le serveur affiche un point d’interrogation. La machine de l’utilisateur, pourtant, a peut-être encore des caractères dans son tampon, et le réseau en transporte d’autres. Les prendre pour une nouvelle instruction ferait d’une simple coquille le chef d’orchestre de la suite. La RFC 860 cherche le point exact où ce vieux texte cesse d’être vieux.

TELNET était une conversation dans les deux sens, avec des données que chaque machine pouvait mettre en attente. Le protocole général définissait cette conversation; les règles des options permettaient aux deux côtés de proposer un comportement supplémentaire ou de le refuser. La marque de synchronisation donnait à ces règles un usage très concret. Son nom évoque une montre; sa fonction, ici, ressemble davantage à un signet glissé dans deux piles de lettres qui se croisent.

Le serveur envoie IAC DO TIMING-MARK. À l’autre bout, une réponse favorable revient sous la forme IAC WILL TIMING-MARK, placée après le passage de la demande par le tampon de sortie vers le terminal et par le tampon d’entrée qui ramène la réponse. La place compte davantage que les octets de la réponse. Quand la marque revient, le serveur sait que les données antérieures ont franchi ce point de retournement. Il peut alors distinguer le texte saisi avant que l’utilisateur ait vu l’erreur de ce qu’il a tapé ensuite.

La recette détaillée dans la RFC commence par un retour à la ligne et un point d’interrogation. Le serveur émet ensuite la demande de marque et un message d’erreur. Il continue à lire l’entrée, mais la jette jusqu’au retour de WILL TIMING-MARK. À partir de là, il interprète à nouveau les touches. Le point souhaité est juste avant le premier caractère que l’utilisateur tape après avoir vu le point d’interrogation. La décision suit donc l’expérience de la personne devant l’écran, et non l’instant auquel le serveur a découvert sa propre difficulté.

La corbeille appartient à l’émetteur de DO. La machine éloignée peut placer une marque fiable dans son flot; elle ne choisit pas quelles commandes l’application du demandeur doit oublier. Cette répartition permet aussi l’opération inverse. Un terminal qui reçoit une avalanche de réponses devenues inutiles peut demander une marque au serveur, cesser d’afficher l’ancien flot jusqu’au WILL, puis montrer ce qui suit la nouvelle commande. Dans les deux sens, le demandeur décide du nettoyage; l’autre côté lui fournit un repère.

Les quatre réponses ont des poids différents. DO sollicite le repère. WILL assure qu’il a été placé au point convenu. WON'T refuse cette assurance, tout en montrant que les données précédentes ont au moins été reçues. DON'T signale qu’un WILL antérieur a été ignoré. Par défaut, les deux extrémités ne cherchent aucune synchronisation explicite. Le document cite aussi la mesure d’un aller-retour comme emploi possible: on peut chronométrer un trajet dont on connaît enfin le point de retour. La marque elle-même reste une position dans le flot.

Postel et Reynolds envisagent même l’utilisateur impatient qui prévoit la demande du serveur. Son terminal peut envoyer WILL à un point choisi par lui, puis reprendre la frappe; le logiciel devra ensuite absorber correctement la demande qui finira par arriver. Ce cas particulier rappelle pourquoi les tampons rendent une conversation moins simple qu’un dialogue face à face. Un serveur peut regretter une commande; il doit encore laisser à l’autre machine le temps de savoir où commence la correction.

L’invention est modeste et précise. L’utilisateur voit son erreur, le serveur reçoit une frontière, et les caractères tapés avant cette frontière peuvent partir à la corbeille. Une conversation TELNET a ainsi un moyen de reprendre au bon mot après avoir trébuché sur le mauvais.