Résumé

  • XDR ne transportait pas la mémoire native d’une machine : il imposait une forme externe unique, en unités de quatre octets et dans un seul ordre.
  • La longueur désignait les octets de la valeur ; le remplissage nul rétablissait l’alignement sans agrandir cette valeur.
  • L’ordre des déclarations et le discriminant d’une union guidaient le décodage, mais le cadrage, la sécurité et le sens applicatif restaient ailleurs.

Le vide devait être reproductible

L’exemple complet de la RFC 4506 encode un nom de fichier de neuf octets. Après la longueur et les neuf caractères viennent trois octets à zéro, puis seulement le champ suivant. Un lecteur pressé pourrait les appeler du gaspillage. Ils accomplissent pourtant deux tâches distinctes : replacer le prochain objet sur une frontière de quatre octets et empêcher le contenu résiduel de la mémoire locale de contaminer la forme externe.

Ces trois zéros ne font pas partie du nom. La longueur reste neuf. Mais ils font partie de l’encodage valide. S’ils étaient laissés au hasard, deux machines pourraient représenter la même valeur avec des suites différentes. Comparaison binaire et somme de contrôle cesseraient alors d’être des propriétés stables.

XDR révèle ici son choix politique le plus fin : les machines pouvaient rester différentes à l’intérieur, à condition d’abandonner ces différences au moment de publier des octets.

Une convention extérieure remplaça les couples de conversions

La RFC 1014, en 1987, présentait XDR comme un langage de description et d’encodage destiné à des architectures très diverses. Sun RPC et NFS l’utilisaient déjà. La syntaxe ressemblait à C, mais elle ne décrivait ni un programme ni la disposition d’une structure en mémoire.

Un entier signé XDR occupe 32 bits en complément à deux, octet de poids fort en premier. Les éléments d’un tableau suivent leur ordre naturel ; les membres d’une structure, l’ordre de déclaration. Chaque hôte peut convertir vers son modèle local. Il ne peut pas déduire un autre ordre au gré de son processeur.

Le format ne commence pas par « petit » ou « grand-boutiste ». Admettre deux ordres aurait exigé un protocole supérieur pour annoncer le choix. En n’en gardant qu’un, XDR rendait aussi un objet stocké interprétable sans retrouver la négociation qui l’avait précédé. La conversion était inégalement coûteuse, mais la règle restait commune.

La largeur de quatre octets relevait elle aussi d’un compromis. Deux octets auraient réduit certains remplissages tout en créant davantage de problèmes d’alignement ; huit auraient favorisé plus d’architectures au prix d’un gonflement général. XDR choisit le milieu, pas une vérité matérielle universelle.

La longueur ne donnait aucun droit au remplissage

Pour une donnée opaque variable, XDR place d’abord un entier non signé de 32 bits, puis exactement le nombre d’octets annoncé, puis zéro à trois octets nuls. Les chaînes suivent cette forme comptée. Les tableaux variables annoncent le nombre d’éléments avant de les dérouler.

Un décodeur dispose ainsi de contrôles locaux : confronter la longueur au maximum du protocole, vérifier les octets disponibles, calculer la prochaine frontière. Dépasser une borne déclarée rend l’encodage erroné. L’absence de borne dans le langage n’ordonne toutefois pas à une machine de réserver une capacité théorique immense ; elle doit encore imposer ses limites de mémoire et de travail.

Une chaîne XDR comptée peut contenir un octet NUL. Une bibliothèque locale qui confond ce NUL avec une fin de chaîne peut allouer selon une mesure et libérer ou comparer selon une autre. La forme canonique règle une différence d’architecture ; elle ne dispense jamais de traduire prudemment vers le type local.

Une union ne s’ouvrait que par son discriminant

XDR emploie un typage implicite. Les champs ordinaires ne voyagent pas avec leur nom et une étiquette de type universelle. Le schéma partagé donne leur place et leur nature. Modifier l’ordre d’une structure publiée revient donc à changer le sens des octets suivants.

L’union discriminée rend au moins le choix de branche explicite. Un entier, une énumération ou un booléen précède l’unique branche autorisée. Sans branche par défaut, une valeur de discriminant inconnue ne possède aucun encodage valide. Les données optionnelles condensent ce principe : vrai annonce un élément ; faux sélectionne void, qui n’occupe aucun octet. L’absence est dite par le choix, non devinée dans une charge vide.

Ce pouvoir reste étroit. Le discriminant sélectionne une forme prévue. Il n’authentifie personne, n’autorise pas un appel distant et ne garantit pas que le contenu est raisonnable.

Le message commençait et finissait dans une autre couche

La RFC 1832 plaça en 1995 la forme déployée sur la voie des standards. La RFC 4506 devint STD 67 en 2006 sans modifier techniquement l’encodage. Elle renforça surtout les considérations de sécurité : bornes explicites, vérification des buffers, prudence face aux NUL intégrés et limites de récursion.

La RFC 5531 sépare clairement les responsabilités. Les messages ONC RPC sont décrits en XDR. Sur TCP, ils reçoivent néanmoins un marquage d’enregistrement distinct, avec des en-têtes de fragments qui ne sont explicitement pas du XDR. Décoder une valeur ne dit donc pas où se termine n’importe quel message TCP, à quel appel elle appartient ni si une opération a été durablement exécutée.

XDR ne chiffre, ne signe et n’autorise rien. Il donne une grammaire vérifiable. Le protocole porteur et l’application conservent la charge de la sécurité, de l’identité, du cadrage et de la décision.

Sources et limites

Le dossier fermé réunit la RFC 1014, la RFC 1832, la RFC 4506 et la RFC 5531. Ces textes prouvent la règle d’encodage, sa continuité et sa frontière avec RPC. Ils ne mesurent pas l’usage actuel, ne certifient aucun produit et ne transforment pas une forme correcte en fait exact ou en action légitime.