Zusammenfassung

  • RFC 1014 von Sun Microsystems beschrieb im Juni 1987 ein Datenformat, dessen Elemente Vielfache von vier Bytes belegen. Variable Zeichenketten tragen zuerst eine vier Byte lange Längenangabe, dann ihre Zeichen und anschließend Nullbytes bis zur nächsten Grenze.
  • Im Beispiel des RFC folgen auf die neun Zeichen von sillyprog drei Nullbytes. Der Dateityp beginnt bei Offset 16. Die Längenangabe zählt den Namen; die Füllung legt die Stelle für das nächste Feld fest.

Der kleine Versatz hinter einem Dateinamen konnte einen ganzen Datensatz verrücken. Im RFC überträgt Sun Microsystems dafür ein bewusst einfaches Beispiel: Ein Benutzer namens john speichert das Lisp-Programm sillyprog mit dem Inhalt (quit). Verschiedene Rechner sollen nach dem Namen denselben Dateityp lesen. XDR schreibt vor den Namen eine vier Byte große 9, danach die neun Zeichen und zuletzt drei Nullbytes. Bei Offset 16 darf der Dateityp auftreten. Die freien Plätze gehören zur Reiseordnung des Datenstroms, nicht zum Namen des Programms.

1987 mussten Daten zwischen Maschinen wandern, die im Inneren unterschiedlich arbeiteten. Der RFC nennt Sun-Workstations, VAX, IBM-PC und Cray. XDR, External Data Representation, bot eine gemeinsame Beschreibung und Kodierung der Werte. Sun RPC und NFS verwendeten es für ihre Datenformate. Die Grundlage war ein transportierbares Acht-Bit-Byte. Darüber legte der Standard ein regelmäßiges Raster: Jedes kodierte Element nahm ein Vielfaches von vier Bytes ein.

Eine 32-Bit-Ganzzahl füllte eine solche Einheit von selbst. Eine Zeichenfolge mit neun Bytes ließ in der dritten Einheit drei Plätze offen. XDR füllte sie mit Nullen. Die Längenangabe blieb 9, weil nur neun Bytes Inhalt waren; im Strom beanspruchten Name und Füllung zusammen zwölf Bytes hinter dem Zähler. Der Empfänger las den Inhalt und übersprang die Nullen. Danach wusste er ohne Rückfrage, wo das nächste Feld beginnt. Die drei überzähligen Bytes bezahlten diese Ortskenntnis.

Der Hexadezimalplan des RFC macht die Rechnung überprüfbar. Die Positionen 0 bis 3 enthalten die Länge 9. Auf 4 bis 12 verteilen sich die neun Buchstaben. An 13, 14 und 15 stehen Nullbytes. Auf 16 folgt EXEC, der Dateityp mit dem Wert 2. Wer die Nullen als Zeichen liest, verändert den Namen. Wer nach dem letzten Buchstaben sofort den Dateityp erwartet, beginnt drei Bytes zu früh. Eine winzige Ungenauigkeit am Anfang verschiebt die gesamte folgende Lektüre.

Im weiteren Beispiel wiederholt sich das Muster bei wechselnden Inhalten. EXEC bestimmt, welcher Zweig einer Union folgt: Hier ist es der Interpreter lisp, angekündigt durch die Länge 4 und gefolgt von vier Zeichen. Der Eigentümer john wird ebenso kodiert. Der Dateiinhalt (quit) hat sechs Bytes, davor steht die Länge 6, dahinter stehen zwei Nullen. Der Leser folgt einem einfachen Ablauf: Länge prüfen, Inhalt lesen, bis zur Vierergrenze vorrücken, nächstes Feld lesen.

Zeichenketten und undurchsichtige Daten sind dabei unterschiedliche Typen. Die Zeichenkette des RFC besteht aus ASCII-Bytes; „opaque“ transportiert Bytes, deren Inhalt XDR nicht deutet. Für variable Werte lässt sich eine Obergrenze angeben; eine größere kodierte Länge ist ein Fehler. Der Zähler erlaubt also sowohl das Auffinden des Inhaltsendes als auch die Prüfung der Grenze. Die Füllbytes beantworten eine andere Frage, nämlich nach dem Beginn des Folgewerts. Inhalt und Wegweiser gemeinsam zu zählen, würde den Wegweiser zum Inhalt machen.

Die Datenbeschreibung verhinderte, dass der Empfänger die Speichergewohnheiten des Senders erraten musste. Ein Zeiger aus einem Programm zeigt auf einem fremden Rechner nicht auf dieselbe Sache. Auch der Aufbau einer lokalen Struktur hängt von Maschine und Übersetzer ab. XDR schrieb Typen, Reihenfolge und Bytefolge des Austauschs fest. Im Dateibeispiel entscheidet EXEC über den folgenden Interpreter-Zweig. Das Vierer-Raster sorgt dafür, dass diese Entscheidung an einer gemeinsamen Position getroffen wird.

Nullbytes kosten Platz: drei beim Namen, zwei beim sechs Byte langen Programmtext. Der RFC führt diese Kosten offen in seinem Offset-Plan auf. Dafür erhält der Empfänger eine ausrechenbare Folge von Feldanfängen. sillyprog darf albern heißen. Am Ende der drei freien Byteplätze steht eine ernste Verabredung: Sun-Workstation, VAX, IBM-PC und Cray können bei Offset 16 denselben Dateityp finden.