Resumo

  • No RFC 1013, de junho de 1987, o primeiro byte da conexão X11 era 102 em octal, a letra B, para o byte mais significativo primeiro, ou 154 em octal, a letra l minúscula, para o byte menos significativo primeiro. Campos comuns de 16 e 32 bits seguiam a escolha do cliente.
  • Bitmaps e pixmaps seguiam o formato de imagem informado pelo servidor, inclusive sua ordem de bytes. O servidor ajustava os valores comuns à ordem do cliente; o cliente ajustava os bytes da imagem à ordem exigida pelo servidor.

Um programa instalado numa estação de trabalho pede uma janela na tela ligada a outra máquina. Envia largura, altura, identificadores de recursos e comandos para desenhar. Se as duas máquinas guardam os bytes de um número em ordens diferentes, o valor pode ser lido de outro jeito no destino. O fio entrega os bytes; ele não explica por qual ponta a tela deve começar a ler. O X colocou essa explicação no primeiro byte da conversa.

O RFC 1013 publicou em junho de 1987 uma atualização alfa do protocolo X versão 11. Clientes remotos podiam usar qualquer fluxo confiável de bytes; sobre TCP, o servidor da tela N aceitava conexões na porta 6000 mais N. Antes de enviar versão e dados de autorização, o cliente escolhia a ordem dos números de 16 e 32 bits. O documento escreveu as opções em octal: 102 significava B maiúsculo em ASCII e byte mais significativo primeiro; 154, l minúsculo e menos significativo primeiro. Não eram dois números decimais mágicos. Eram a maneira de declarar quem devia virar os bytes.

Nos campos comuns, o cliente mandava. O servidor trocava os bytes quando sua ordem nativa era diferente e devolvia valores multibyte no mesmo padrão, salvo exceção explícita. Assim, o programa não precisava conhecer o interior do computador que comandava a tela para pedir um retângulo. O servidor recebia o trabalho de tradução. A primeira letra da ligação funcionava como uma pequena ordem de serviço.

Quando chegavam os pixels, a autoridade mudava de lugar. Dados de bitmap e pixmap tinham de obedecer aos formatos anunciados pelo servidor. Sua resposta de configuração trazia image-byte-order, unidade e preenchimento das linhas de bitmap, formatos de pixmap e outras características da tela. Em XYFormat, a ordem se aplicava a cada unidade de linha; em ZFormat, a cada valor de pixel. Se o cliente montava imagens numa ordem diferente, cabia a ele trocar os bytes antes do envio. A máquina que mostraria a figura escolhia a embalagem da figura.

Essa divisão tinha uma consequência de implementação bem concreta. Um aplicativo poderia enviar dimensões corretas, receber identificadores corretamente e ainda organizar os bytes da imagem com a regra errada. O RFC especifica os dois trabalhos de conversão. A possibilidade de erro decorre dessas regras; não é preciso inventar um episódio de tela corrompida para torná-la compreensível. O fato de a janela abrir não prova que os pixels seguintes foram preparados para aquele servidor.

O começo da conexão continha mais informações: versão do protocolo esperada pelo cliente e nome e dados da autorização. O servidor respondia com sua versão e o resultado da abertura; quando aceitava, descrevia recursos e formatos de imagem. O núcleo do documento deixava os mecanismos válidos de autorização para outros acordos. Aqui a sequência importa pelo seu efeito prático. O primeiro byte torna os comandos legíveis. A resposta do servidor torna a imagem montável.

O desenho distribuiu uma conta que não desaparecia por decreto. Para os comandos, o servidor acomodava clientes diferentes; para os pixels, cada cliente acomodava a tela. Uma mesma janela podia unir máquinas de hábitos opostos porque ambas sabiam onde fazer a tradução. O protocolo não pediu que todos tivessem o mesmo estômago. Pediu que cada um lesse a parte do outro na ordem certa.