RFC 2188 : quand l’échec d’un côté ne dit pas ce que l’autre sait

Résumé

• RFC 2188 ne proposait pas une notion magique de « succès exactement une fois » : il distinguait l’invocation, son exécution, le retour d’un résultat ou d’une erreur, l’acquittement, puis les confirmations et échecs observés localement.
• En mode avec résultat acquitté, un FAILURE.indication côté exécutant peut être compatible avec un résultat déjà reçu par l’invocateur ; en mode non acquitté, certaines confirmations côté exécutant n’expriment aucune connaissance du pair.
• ESRO déléguait aux déployeurs les temporisations et hypothèses réseau, tandis que l’authentification, l’idempotence, le commit durable et la réconciliation restaient hors du protocole.

Un échec qui ne réécrit pas le passé

Le cas le plus instructif de RFC 2188 commence après une réussite.

L’exécutant — le performer — a accompli l’opération et envoyé un PDU de résultat. L’invocateur — l’invoker — le reçoit et l’accepte. Pourtant, si l’acquittement attendu n’atteint pas l’exécutant, celui-ci peut finir par signaler FAILURE.indication.

Il serait tentant de traduire ce signal par : « l’autre extrémité n’a pas obtenu le résultat ». Ce serait précisément ce que le protocole ne permet pas de conclure.

Dans le mode à résultat acquitté d’ESRO, la confirmation RESULT.confirm ou ERROR.confirm du côté exécutant intervient après réception de l’ACK envoyé par l’invocateur. Si cet ACK se perd, l’exécutant manque la preuve protocolaire attendue. Mais la perte de cette preuve ne détruit pas la réception antérieure du résultat chez l’invocateur. Une autre possibilité est que le PDU de résultat ou d’erreur lui-même ait été perdu ; une défaillance locale du fournisseur ESRO peut aussi conduire au même type d’indication. Le même signal local recouvre donc plusieurs histoires réseau incompatibles entre elles.

C’est une distinction de portée générale, mais RFC 2188 la formule dans un mécanisme très concret : une extrémité sait ce que ses propres événements lui permettent de savoir. Elle ne possède pas automatiquement l’état mental du pair.

ESRO : économiser les échanges sans abolir l’incertitude

RFC 2188, publié en septembre 1997 comme RFC Informational, décrit Efficient Short Remote Operations, ou ESRO. Le document n’était pas un Internet Standard ; il n’était pas issu d’une revue par un groupe de travail IETF, et l’IESG y joignait notamment un avertissement sur la montée en charge.

L’objectif était étroit : fournir des opérations distantes fiables, de faible surcharge, au-dessus d’UDP, avec un intérêt particulier pour des liaisons où chaque échange coûtait davantage qu’il ne coûte sur un réseau local généreux. Le texte cite notamment le contexte des réseaux sans fil tels que CDPD.

Le choix d’UDP était donc lié à un protocole qui ajoutait lui-même les mécanismes nécessaires à son modèle d’opération. ESRO utilisait le port UDP 259 et prévoyait notamment segmentation et réassemblage, concaténation et séparation, ainsi que multiplexage applicatif.

L’économie centrale portait aussi sur le nombre d’étapes. ESRO définissait deux formes d’échange : un mode en trois temps avec résultat acquitté et un mode en deux temps sans acquittement du résultat.

Ces deux modes ne constituent pas simplement deux vitesses du même niveau de certitude. Ils changent la nature de ce que l’exécutant peut inférer.

Trois temps : le prix d’une preuve supplémentaire

Dans le mode acquitté, l’invocateur envoie l’invocation. L’exécutant renvoie un résultat ou une erreur. L’invocateur accuse ensuite réception.

Cette dernière étape apporte à l’exécutant une information provenant du pair. C’est pourquoi sa confirmation n’est produite qu’après réception de cet ACK.

La nuance importe : ESROS-RESULT signifie qu’une opération a été exécutée avec succès ; ESROS-ERROR signale au contraire une opération exécutée sans succès. Mais les événements ultérieurs de confirmation et d’échec appartiennent à un autre plan. Ils décrivent ce que la mécanique protocolaire a pu établir après l’envoi du résultat ou de l’erreur.

Mélanger ces plans produit de fausses certitudes.

Une opération peut avoir été exécutée avec succès, son résultat avoir été construit, transmis et même indiqué à l’invocateur, tandis que l’exécutant reste incapable de confirmer que son message de résultat a reçu l’acquittement attendu. Son échec local ultérieur ne transforme donc pas une réussite applicative antérieure en non-exécution.

RFC 2188 indique qu’une opération séparée de vérification peut servir de remède lorsque l’ambiguïté doit être levée. C’est une réponse significative : plutôt que de prétendre que le premier échange transporte nécessairement toute la vérité, le protocole admet qu’un second acte peut être requis pour apprendre l’état pertinent.

Deux temps : finir localement n’est pas apprendre du pair

Le mode non acquitté réduit encore l’échange.

Dans ce cas, RESULT.confirm et ERROR.confirm côté exécutant sont générés sans information reçue du pair. RFC 2188 leur retire ainsi toute signification protocolaire au-delà de la fin locale de l’opération.

Ce point est facile à manquer parce que le mot « confirm » semble plus fort qu’il ne l’est. Ici, il ne signifie pas « l’autre extrémité a reçu ce résultat ». Il signifie seulement que le fournisseur local est arrivé au terme prévu de son traitement.

Le protocole ne génère d’ailleurs pas de FAILURE.indication côté exécutant dans ce mode. Il ne dispose pas du dialogue supplémentaire qui lui permettrait de tirer une conclusion correspondante.

Côté invocateur, un échec peut en revanche signifier qu’aucun résultat, aucune erreur ni indication de défaillance attendue n’est arrivé, ou qu’une défaillance locale du fournisseur invocateur s’est produite. Là encore, le symptôme observable ne suffit pas toujours à reconstituer l’histoire unique du système.

Deux rôles, deux journaux de vérité partielle

La terminologie d’ESRO évite un piège fréquent de l’histoire des RPC : imaginer une « opération » comme un objet unique observé uniformément par tout le monde.

L’invocateur et l’exécutant sont des rôles distincts. Chacun traverse une suite d’événements qui n’est ni identique ni nécessairement symétrique.

On peut décomposer l’opération en couches successives :

l’invocation demandée ; sa livraison ; l’exécution chez l’exécutant ; la construction d’un résultat ou d’une erreur ; la livraison de ce résultat ou de cette erreur ; l’indication correspondante chez l’invocateur ; l’ACK éventuel ; la confirmation ou l’échec local ; puis, hors de cette mécanique, l’authentification, l’idempotence applicative, le commit durable et une éventuelle réconciliation ultérieure.

Aucune de ces couches ne démontre automatiquement toutes les suivantes.

Recevoir l’invocation ne prouve pas que l’effet métier a été durablement inscrit. Exécuter l’opération ne prouve pas que le résultat a été reçu. Recevoir le résultat ne prouve pas que l’exécutant a reçu son ACK. Un timeout ne prouve pas l’absence d’effet. Une confirmation locale ne prouve pas une vérité commerciale partagée.

La conception de RFC 2188 est donc intéressante moins par sa ressemblance avec des abstractions modernes que par son refus de les confondre.

Les Invoke IDs corrèlent ; ils ne garantissent pas le reste

ESRO utilise des identifiants d’invocation pour corréler des échanges. Mais la corrélation n’est pas une garantie d’authenticité, ni une propriété d’idempotence, ni la preuve d’un commit commercial.

Un identifiant permet au protocole de reconnaître à quelle invocation appartient un élément de dialogue. Il ne transforme pas une requête en opération sans effet de bord répétable à volonté.

Cette frontière est essentielle lorsque les retransmissions entrent en jeu. Un protocole peut retransmettre pour augmenter la probabilité de livraison. Une application, elle, doit encore décider ce qu’une répétition signifie pour son propre état.

Une commande idempotente supporte naturellement certains doublons. Une commande non idempotente — par exemple une action externe irréversible — peut transformer une ambiguïté de livraison en double effet réel si l’application répond mécaniquement à un timeout par une nouvelle exécution.

RFC 2188 n’essaie pas de résoudre cette politique métier par un numéro d’invocation.

Des minuteries choisies pour un réseau réel

ESRO ne fixe pas une seule personnalité temporelle valable pour tous les déploiements. Les paramètres de retransmission, le nombre maximal de retransmissions, le délai d’inactivité et la durée de vie des numéros de référence sont des choix du déployeur adaptés au réseau.

Cette flexibilité complète la logique du protocole : ESRO cherche une faible surcharge, mais la fiabilité pratique dépend de valeurs choisies en fonction du délai, des pertes et du comportement attendu du support.

Une temporisation trop courte peut provoquer des retransmissions inutiles et accroître le risque de doublons observés par l’application. Une temporisation trop longue retarde au contraire la détection d’une absence de progression. La durée de vie des références interagit avec la réutilisation des identifiants : oublier trop tôt l’ancien contexte peut rendre une arrivée tardive plus difficile à interpréter correctement.

La mécanique fiable n’est donc pas un attribut abstrait d’ESRO. Elle résulte aussi de paramètres d’exploitation.

L’authentification est ailleurs

RFC 2188 est également net sur ce qu’ESRO ne fournit pas : le protocole n’intègre pas d’authentification.

La responsabilité de l’authentification revient à l’exécutant, en dehors d’ESRO. Cette séparation empêche d’interpréter la réception d’une invocation, la présence d’un Invoke ID ou le bon déroulement d’une poignée de main comme preuve d’identité autorisée.

Cela vaut également pour l’encodage. Le protocole peut transporter l’indication d’un type d’encodage, mais la sémantique détaillée de l’encodage des paramètres n’est pas son objet.

Le protocole définit donc une discipline de transport d’opérations courtes ; il ne définit ni l’identité des acteurs, ni les règles métier qui rendent leurs requêtes acceptables.

Ni « exactement une fois », ni transaction distribuée

Lire RFC 2188 comme une étape vers les mythes génériques de l’« exactly once » écraserait ce qui fait son intérêt.

Le texte ne prétend pas qu’un service distant possède une vue atomique universelle de l’exécution, de la livraison et du commit. Il décrit au contraire comment les connaissances se séparent selon les événements réellement observés.

Ce n’est pas non plus un protocole de transaction distribuée au sens moderne. Il ne transforme pas plusieurs participants en un domaine de commit commun, ne fournit pas d’idempotence métier automatique et ne règle pas la réconciliation après une action externe irréversible.

Son apport historique est plus précis : montrer qu’une opération distante efficace peut être fiable sans que toutes les extrémités acquièrent au même instant le même niveau de certitude.

RFC 2524 : un usage prévu, pas un verdict historique

RFC 2524 a ensuite spécifié une soumission et une remise efficaces du courrier au-dessus d’ESRO. Cela documente un usage prévu de la pile et permet de voir comment le mécanisme pouvait être incorporé à une application concrète.

Il ne démontre ni la prévalence actuelle d’ESRO, ni un succès universel, ni des performances commerciales particulières.

La distinction est la même que pour l’opération elle-même : une preuve de conception ou d’usage prévu ne doit pas être étendue au-delà de ce qu’elle établit.

Ce que RFC 2188 savait déjà en 1997

Le point le plus durable de RFC 2188 n’est peut-être pas son port UDP, ni même son économie de messages. C’est sa discipline épistémique.

Le protocole sait que « le résultat a été exécuté », « le résultat a été envoyé », « l’invocateur l’a reçu », « l’ACK est revenu » et « l’exécutant possède maintenant une confirmation » sont des propositions différentes.

Leur enchaînement habituel peut les faire paraître équivalentes. La perte d’un seul paquet révèle qu’elles ne le sont pas.

ESRO construit donc son efficacité autour d’un choix explicite : quel niveau de connaissance supplémentaire vaut un message supplémentaire ? Le mode acquitté paie pour une preuve provenant du pair. Le mode non acquitté renonce à cette preuve lorsque la fin locale suffit.

Cette économie de messages est inséparable d’une économie de certitude.