Résumé

  • TCP livrait un flux d’octets fiable et ordonné, sans préserver les frontières des appels et réponses ; ONC RPC plaça donc chaque message dans un record composé d’un ou plusieurs fragments.
  • Le marqueur big-endian de quatre octets consacrait 31 bits à la longueur du fragment et le bit supérieur à une seule décision : le record finit après ces données.
  • La fin du record n’attestait ni XDR, ni identité, ni autorisation, ni exécution ; elle rendait seulement la frontière du message calculable.

Le flux n’arrivait pas avec les coupures de l’émetteur

Un client écrit un CALL en une fois. Le serveur peut pourtant recevoir les trois premiers octets, puis le reste du marqueur, puis la moitié du contenu. À l’inverse, une lecture généreuse peut rapporter deux records complets et le début du troisième. Aucun de ces résultats ne viole TCP.

RFC 793 avait fait du transport un service d’octets ordonnés. Il avait aussi refusé de transformer PUSH en marqueur de record. RFC 9293 conserve aujourd’hui cette définition du byte stream. Les segments déplacent le flux ; ils ne décrivent pas la grammaire de l’application.

La métaphore de la procédure distante exigeait pourtant des messages distincts : un CALL devait finir avant que le suivant puisse être interprété, et une REPLY devait pouvoir être isolée. La frontière devait donc apparaître dans une couche qui connaissait RPC.

Deux mois de 1988 ont figé quatre octets

RFC 1050, publié en avril 1988, nomma la solution record marking. Un message RPC tenait dans un record RM ; un record comprenait un ou plusieurs fragments. RFC 1057 remplaça le texte en juin sans modifier cette construction.

Chaque fragment commence par un entier non signé de quatre octets, transmis de l’octet fort vers l’octet faible. Les 31 bits inférieurs annoncent la quantité de données de ce fragment, de zéro à 2^31 - 1. Le bit supérieur est booléen : zéro annonce un autre fragment du même record ; un annonce le dernier.

Le record ne s’achève pas au moment où le lecteur voit le bit à un. Il s’achève après réception de la longueur annoncée. De même, épuiser les octets d’un fragment marqué zéro ne crée pas un message partiel acceptable : les quatre octets suivants doivent décrire le fragment suivant du même record.

Le récepteur devait compter avant d’interpréter

Le parseur accumule d’abord quatre octets, même si plusieurs lectures sont nécessaires. Il sépare ensuite le bit et la longueur, puis consomme exactement cette quantité du flux. Il conserve les fragments dans le contexte du record courant ou les traite progressivement sous une limite locale.

Quand le bit vaut zéro, il recommence avec un nouveau marqueur. Quand il vaut un, le record devient un message RPC complet et les quatre octets suivants, s’ils sont déjà présents, appartiennent au record suivant. Cette machine à états ne dépend ni des paquets ni de la taille des appels à l’API de lecture.

Une longueur nulle est comprise dans le domaine défini. Le fragment n’apporte aucune donnée, mais son bit décide encore s’il poursuit ou ferme le record. En revanche, une connexion interrompue au milieu du corps annoncé ne produit pas un petit record valide. Elle laisse un fragment inachevé et ne renseigne pas sur ce que le serveur distant avait déjà exécuté.

Fragment ne voulait pas dire paquet

Le mot apparaît à plusieurs étages. Le fragment RM n’est ni un fragment IP, ni un segment TCP, ni un buffer d’écriture, ni un champ XDR. Il peut traverser plusieurs segments. Une seule fenêtre de réception peut contenir plusieurs fragments et plusieurs records. Une retransmission peut modifier le découpage visible sans changer un seul octet du message reconstitué.

Le bit final n’est donc ni FIN, ni PSH, ni fin de fichier, ni acquittement. CALL et REPLY sont des messages distincts et reçoivent chacun leur record sur TCP. La fin correcte d’un record peut entourer une version de programme inconnue, des arguments invalides ou un refus d’authentification.

La différence avec PUSH est nette. PUSH porte une demande de mouvement plus prompt des octets disponibles. Record marking porte une règle de syntaxe : combien d’octets composent ce fragment et si un autre fragment appartient encore au même message.

Le conteneur n’était pas une valeur XDR

À l’intérieur, ONC RPC emploie External Data Representation. RFC 4506 établit l’ordre canonique des nombres, les longueurs, le remplissage et les types qui rendent un message lisible par des architectures différentes.

Les spécifications RPC précisent pourtant que le marqueur de record n’est pas en forme XDR standard. Il ressemble à un entier XDR par son ordre d’octets, mais il doit être compris avant que le message RPC entier puisse être décodé. Utiliser le schéma interne pour retrouver la limite externe ferait dépendre le cadrage de la valeur qu’il cherche justement à isoler.

Une frontière correcte et un contenu correct restent donc deux verdicts. Le récepteur peut refuser un cadrage excessif avant de toucher à la procédure. Il peut aussi recevoir un record parfaitement fermé dont le XDR ou le protocole RPC est faux.

Trente et un bits n’étaient pas une réservation de mémoire

La longueur borne un fragment, jamais le record complet. Plusieurs fragments peuvent s’enchaîner, et le format de base ne promet pas une limite cumulative unique. Allouer aveuglément la valeur annoncée transforme une coordonnée fournie par le réseau en pouvoir sur la mémoire du récepteur.

Une implémentation doit donc définir ses propres budgets de taille cumulée, de nombre de fragments, de mémoire simultanée et de durée. C’est une conséquence opérationnelle, non une nouvelle valeur normative attribuée au RFC. La télémétrie doit conserver la demande et la limite locale afin d’expliquer le refus.

Le texte historique dit que les records aident à détecter et éventuellement récupérer des erreurs de protocole. Il ne définit pas une recherche magique du prochain entier plausible. Des données ordinaires peuvent imiter un marqueur. Après une violation, fermer le flux est parfois plus sûr que de réattribuer des octets au mauvais appel.

Le format survécut jusqu’au transport qui devait le remplacer

RFC 1831 reprit la règle en 1995. RFC 5531 l’actualisa en 2009 sans changement du protocole sur le fil. Sa stabilité venait de son office limité : fournir à TCP la frontière qu’il ne prétendait pas connaître.

RFC 8166 montre que l’office dépend du transport. RPC-over-RDMA possède ses propres flux de transport et de charge utile et remplace tout autre cadrage RPC, y compris le record marking TCP, même si RDMA repose lui-même sur un transport qui le connaît. Un basculement dynamique doit se produire entre deux messages RPC distincts.

Le mécanisme de 1988 n’était donc pas une propriété éternelle d’une procédure. Il était l’adaptateur exact entre un modèle de messages et un flux d’octets.

Portée des sources

Le dossier fermé réunit RFC 793, RFC 1050, RFC 1057, RFC 1831, RFC 4506, RFC 5531, RFC 8166 et RFC 9293. Ces textes établissent le format, son histoire et ses frontières. Ils ne mesurent pas l’usage actuel, ne certifient aucune bibliothèque et ne prouvent ni identité, ni autorisation, ni résultat dans une connexion réelle.

Le bit supérieur fut durable parce qu’il resta modeste. Il permettait de dire « le message finit ici » sans ajouter « et le monde extérieur a accompli ce qu’il demandait ».