Résumé

  • Le RFC 1013, publié en juin 1987, commence la connexion X11 par un octet : 102 en octal, la lettre B, signifie « octet de poids fort d'abord » ; 154 en octal, la lettre l minuscule, signifie l'inverse. Les champs ordinaires de 16 et 32 bits suivent ce choix du client.
  • Pour les données d'image, le serveur fixe le format et l'ordre des octets. Il adapte les champs de protocole à l'ordre demandé par le client ; le client adapte les octets de l'image au format annoncé par le serveur.

Une application veut ouvrir une fenêtre sur l'écran d'une autre machine. Elle envoie des dimensions, des identifiants de ressources, puis des opérations graphiques. Si les deux machines rangent les octets d'un nombre dans des sens opposés, une largeur peut devenir une autre largeur. L'écran ne va pas lire dans les pensées du programme. Il lui faut une règle explicite avant la première commande. Le système X a choisi de la placer tout au début de la conversation.

Le RFC 1013 décrit une mise à jour alpha du protocole X version 11. Pour un client distant, il accepte un flux d'octets fiable ; dans le cas de TCP, le serveur de l'écran N reçoit au port 6000 plus N. Le premier octet envoyé par le client indique comment interpréter les nombres à plusieurs octets. Les valeurs 102 et 154 sont écrites en octal dans le document. Elles désignent respectivement B majuscule et l minuscule en ASCII. La première lettre ne fait pas la politesse : elle distribue le travail de conversion.

Pour les champs ordinaires, le client donne le rythme. Les nombres de 16 et 32 bits qu'il envoie, et ceux que le serveur lui renvoie, suivent cet ordre sauf exception indiquée. Le serveur échange les octets si son propre processeur les range autrement. Ainsi l'application peut parler sans apprendre au préalable la cuisine interne de la machine qui pilote l'écran. Le serveur, lui, sait exactement quel service de traduction assurer.

L'image ne suit pas cette hiérarchie. Pixmaps et bitmaps sont décrits dans le format du serveur. Sa réponse d'ouverture annonce l'ordre des octets des images, l'unité et le bourrage des lignes bitmap, ainsi que les formats de pixmap disponibles. Dans le format XY, l'ordre concerne chaque unité de ligne ; dans le format Z, chaque valeur de pixel. Si l'ordre natif du client diffère, c'est à lui de permuter les octets avant l'envoi. Le même lien contient donc des commandes que le serveur traduit et des pixels que le client prépare.

Ce partage évite de faire comme si tous les ordinateurs avaient le même ventre. Il crée aussi un piège précis pour le programmeur pressé. Les dimensions de la fenêtre peuvent être décodées sans faute, alors que les octets de l'image restent dans l'ordre de la machine expéditrice. Le document explique la règle qui permet d'éviter cette erreur ; nul besoin d'inventer un incident historique pour voir ce que ferait une conversion oubliée.

Après le premier B ou l, le client envoie sa version attendue et des informations sur la méthode d'autorisation. Le serveur répond par sa version et l'état de la connexion, puis, si elle est acceptée, par les caractéristiques des ressources et des images. Le mécanisme précis d'autorisation relève d'autres accords. Dans cette histoire, la séquence d'ouverture sert surtout à savoir qui lit quoi : la lettre rend les commandes interprétables, la réponse du serveur rend les images préparables.

Le plus drôle est que chaque côté commande une matière différente. Le client fixe la grammaire des nombres de la conversation. Le serveur fixe celle de l'image qu'il doit afficher. Le protocole n'a pas choisi une machine souveraine ; il a confié deux tâches de conversion à deux machines. Pour que la fenêtre apparaisse sur un écran éloigné, il fallait d'abord que chacun sache où finit son dictionnaire et où commence celui de l'autre.