Resumen

  • En el RFC 1013, publicado en junio de 1987, el primer byte de una conexión X11 era 102 en octal —B mayúscula, byte más significativo primero— o 154 en octal —l minúscula, byte menos significativo primero—. Los campos ordinarios de 16 y 32 bits seguían la elección del cliente.
  • Los datos de imagen seguían los formatos anunciados por el servidor, incluido su orden de bytes. El servidor adaptaba los campos normales a la elección del cliente; el cliente preparaba los bytes de imagen para la pantalla del servidor.

Un programa en una estación de trabajo pide abrir una ventana en la pantalla de otra. Tiene que enviar tamaños, identificadores de recursos y órdenes de dibujo. Si ambas máquinas colocan los bytes de un número en sentidos opuestos, una anchura puede leerse como otra cosa. No basta con que el cable funcione. Alguien debe decidir qué extremo del número se lee primero, antes de que la primera ventana termine convertida en un malentendido geométrico.

El RFC 1013 recogió en junio de 1987 una actualización alfa del protocolo X versión 11. Permitía a los clientes remotos usar cualquier flujo fiable de bytes; cuando se usaba TCP, el servidor de la pantalla N escuchaba en el puerto 6000 más N. El primer byte que mandaba el cliente definía el orden de los valores de 16 y 32 bits. Las cifras del RFC están en octal: 102 correspondía a la B de ASCII y al byte más significativo primero; 154, a una l minúscula y al menos significativo primero. Era una instrucción de lectura, no una fecha secreta ni una pareja de puertos.

En las órdenes normales mandaba el cliente. El servidor intercambiaba bytes cuando su representación nativa no coincidía y devolvía los valores multibyte en el orden elegido, salvo excepciones expresas. El programa no tenía que saber cómo guardaba cada número la máquina de la pantalla. El servidor asumía ese trabajo de traducción al recibir y responder. Una sola letra al inicio fijaba el idioma numérico de la conversación.

Luego llegaban las imágenes y cambiaba el jefe. Los pixmaps y bitmaps seguían formatos definidos por el servidor. Su respuesta inicial anunciaba image-byte-order, unidad y relleno de las líneas bitmap y formatos de pixmap admitidos. En XYFormat el orden se aplicaba a cada unidad de línea; en ZFormat, a cada valor de píxel. Un cliente con un orden nativo diferente tenía que intercambiar los bytes de la imagen antes de enviarla. La pantalla decidía cómo quería recibir sus píxeles.

La diferencia tiene consecuencias visibles para quien implementa el protocolo. Puede descodificar bien el tamaño de la ventana, asignar recursos sin problemas y aun así preparar mal la imagen si extiende la regla del cliente a los datos gráficos. El RFC explica qué lado hace cada conversión. El fallo es una inferencia directa de ignorar la segunda regla; el documento no ofrece una anécdota de una pantalla histórica arruinada que haga falta repetir.

La apertura incluía además la versión esperada y un nombre y datos de autorización; el servidor devolvía su versión, el resultado de la conexión y los formatos que ofrecía. El núcleo de X no fijaba allí una única técnica válida de autorización. Para esta historia, importa la secuencia: la primera letra hace legibles las órdenes, la respuesta del servidor explica cómo formar las imágenes. Quien se salte cualquiera de las dos conversaciones puede entender los números y perder la fotografía.

El arreglo repartía la factura de la compatibilidad. El servidor se adaptaba al cliente para los valores ordinarios; el cliente se adaptaba al servidor para los píxeles. La red no obligó a todos los ordenadores a tener las mismas tripas. Les obligó a decir en voz alta quién traducía qué. Una ventana compartida empezó con esa pequeña negociación laboral.