Zusammenfassung

  • Im RFC 1013 beginnt eine X11-Verbindung mit einem Byte: oktal 102, das große B, bedeutet höchstwertiges Byte zuerst; oktal 154, das kleine l, bedeutet niederwertiges Byte zuerst. Gewöhnliche 16- und 32-Bit-Protokollwerte folgen der Wahl des Clients.
  • Bilder folgen den vom Server bekanntgegebenen Formaten einschließlich seiner Bild-Byte-Reihenfolge. Der Server tauscht bei gewöhnlichen Feldern nötigenfalls Bytes; der Client richtet Bildbytes für den Server her.

Eine Anwendung auf einer Arbeitsstation will ein Fenster auf dem Bildschirm eines anderen Rechners öffnen. Dafür schickt sie Maße, Ressourcenkennungen und Zeichenbefehle. Liegen mehrbyteige Zahlen in den beiden Maschinen in umgekehrter Reihenfolge, kann aus einer Breite eine andere Breite werden. Das Kabel hat alle Bytes geliefert und trotzdem nichts erklärt. Die beiden Seiten müssen vor der ersten Zeichnung festlegen, an welchem Ende der Zahl die Lektüre beginnt.

Der im Juni 1987 veröffentlichte RFC 1013 dokumentierte eine Alpha-Aktualisierung der elften Version des X-Protokolls. Ein entfernter Client konnte jeden zuverlässigen Bytestrom benutzen; bei TCP nahm der Server für Anzeige N Verbindungen auf Port 6000 plus N an. Das erste Byte des Clients wählte die Reihenfolge der 16- und 32-Bit-Werte. Die Zahlen 102 und 154 stehen im RFC ausdrücklich in oktaler Schreibweise: ASCII B für höchstwertiges Byte zuerst, ASCII l für niederwertiges zuerst. Der Anfangsbuchstabe war eine Arbeitsanweisung an die Gegenstelle.

Bei den normalen Protokollfeldern gab der Client die Richtung vor. Der Server vertauschte Bytes, wenn sein Rechner sie anders ablegte, und lieferte mehrbyteige Antworten in derselben gewählten Reihenfolge, sofern keine Ausnahme festgelegt war. Die Anwendung musste die native Zahlenordnung des Bildschirmrechners vor der Fensteranfrage nicht ermitteln. Diese Übersetzung lag beim Server. Ein einziges Zeichen entschied, wer mit dem fremden Zahlenbau zurechtkommen musste.

Beim Bild wechselte die Zuständigkeit. Bitmaps und Pixmaps verwendeten Formate des Servers. In seiner Antwort zu Beginn der Verbindung nannte er image-byte-order, Einheit und Auffüllung der Bitmap-Zeilen sowie verfügbare Pixmap-Formate. Für XYFormat galt die Bild-Byte-Reihenfolge je Einheit einer Scanline, für ZFormat je Pixelwert. Hatte der Client eine andere native Reihenfolge, musste er Bildbytes selbst passend umstellen. Der Rechner mit dem Bildschirm bestimmte die Verpackung des Bildes.

Diese Trennung stellte eine praktische Falle auf. Ein Programm konnte Fenstermaße richtig senden und Kennungen richtig lesen, dann aber die Pixel mit der Byte-Reihenfolge des Clients verpacken. Der Server hatte für Bilddaten seine eigene Ordnung angekündigt. Die Fensteranfrage war damit sauber verstanden, die Bilddaten wären falsch vorbereitet. Die Probe für einen Implementierer lag genau an diesem Übergang: Befehlsfelder nach dem Anfangsbuchstaben lesen, Bildbytes nach den Formatangaben der Serverantwort bauen.

Zum Verbindungsbeginn gehörten außerdem die erwartete Protokollversion sowie Name und Daten einer Autorisierungsmethode. Der Server meldete seine Version und das Ergebnis zurück und beschrieb bei Annahme Ressourcen und Bildformate. Der Kerntext legte die gültigen Autorisierungsmechanismen nicht selbst fest. Für die Byte-Reihenfolge zählt die Abfolge: Der erste Buchstabe macht die Befehle lesbar; die Antwort des Servers zeigt dem Client, wie das Bild zu bauen ist.

Beide Seiten hatten also recht, aber für verschiedene Bereiche. Der Client regierte die Zahlen der Unterhaltung, der Server die Pixel seiner Anzeige. Die eigentliche Ingenieursfrage lautete: Wer übersetzt? RFC 1013 beantwortete sie zweimal. Andersartige Rechner konnten ein Fenster teilen, weil das Protokoll die Arbeit an der Grenze zwischen ihnen genau verteilte.