Résumé

  • Le RFC 1045 de David Cheriton, paru en février 1988, décrivait VMTP, un transport expérimental pour les transactions de type requête-réponse. L’identité d’une transaction associait Client, numéro de Transaction sur 32 bits et compteur de transfert ; un état conservé côté serveur écartait les doublons.
  • Pour une réponse déclarée idempotente, le client renvoyait sa requête après une perte et le serveur refaisait l’opération. Pour une réponse à préserver, il gardait une copie ou attendait un acquittement. Redemander l’heure donnait même une valeur plus récente.

Un tiroir d’archives et une horloge proposent deux façons de traiter la même panne. Le serveur a produit sa réponse, mais le client ne l’a pas reçue. Dans le RFC 1045, David Cheriton explique comment son Versatile Message Transaction Protocol répartissait le coût de cette disparition. VMTP visait notamment les appels de procédure à distance sur un service de datagrammes capable de perdre des paquets. La question pratique était simple : que doit-on conserver lorsque le travail a peut-être déjà été fait ?

Avant de répondre, il fallait reconnaître la visite. Dans un domaine d’entités, une transaction était repérée par le Client, un numéro de Transaction et un ForwardCount. Le numéro, sur 32 bits, partait d’une valeur aléatoire à la création du Client puis progressait normalement d’une transaction à l’autre. Le compteur de transfert, sur quatre bits, restait à zéro tant que la requête n’était pas réacheminée. Le serveur conservait un dossier d’état par client ; une requête portant les mêmes coordonnées pouvait être reconnue comme doublon. Le protocole avait donc un guichet qui savait distinguer « encore moi » de « nouveau dossier ».

Ce guichet avait lui-même besoin d’une durée de mémoire. Après avoir répondu, le serveur gardait normalement l’état un certain temps afin qu’une vieille copie de la requête ne relance pas l’application. Si l’état manquait, le RFC offrait trois chemins : interroger le module de gestion du client avec Probe ; déduire la nouveauté d’une conservation couvrant la vie maximale des paquets et les retransmissions, à condition de ne pas avoir redémarré ; ou refaire une opération connue pour être sans dommage à la répétition. Un simple bouton « réessayer » cache beaucoup de comptabilité.

Pour la réponse marquée idempotente, VMTP choisissait l’horloge. Le serveur ne gardait pas l’ancienne réponse. Après une perte, le Client renvoyait sa Request et le serveur confiait de nouveau l’opération à l’application. Seule la dernière transaction du client bénéficiait de ce traitement ; les vieilles requêtes retardées étaient écartées. L’exemple du RFC est l’heure actuelle. En la redemandant, on obtient une lecture plus récente que la copie soigneusement classée au premier essai. Le fonctionnaire qui dérange l’horloge travaille parfois mieux que celui qui retrouve son dossier.

Une réponse dont le résultat devait rester unique demandait l’autre solution. Le module VMTP devait conserver une copie, éventuellement par copie sur écriture, ou empêcher le serveur de poursuivre jusqu’à l’acquittement. La mémoire ou l’attente payaient pour préserver le résultat initial. Une consultation d’heure peut être répétée ; une opération qui change un solde ou un registre réclame une autre discipline. La décision appartient au sens de l’opération, pas à la beauté de son paquet.

Le protocole cherchait aussi à réduire les frais du transport. Dans un réseau où les pertes étaient rares, une retransmission pouvait n’envoyer que le bloc de contrôle, et le destinataire demander précisément les données manquantes. Une requête ultérieure pouvait solder les réponses précédentes dans la comptabilité du protocole. Voilà trois budgets sur la même table : la mémoire du serveur, les octets renvoyés et le temps passé à refaire le travail.

L’image du tiroir est comique jusqu’au moment où la mauvaise opération a été répétée. VMTP protégeait le guichet avec ses identifiants, son état conservé et sa règle de dernière transaction. L’application devait, elle, dire sincèrement quelles tâches supportaient une seconde exécution. Le RFC présentait une conception expérimentale, et son intérêt historique tient à ce partage explicite : quand une réponse disparaît, quelqu’un paie pour la retrouver ou pour la refaire.