Zusammenfassung

  • STRU P stellte diskontinuierliche Dateien als unabhängige indexierte Seiten dar; der Page Index bezeichnete die logische Stelle, nicht die Übertragungsreihenfolge.
  • Leere Einträge der Seitentabelle wurden ausgelassen. Eine tatsächlich vorhandene Seite mit Nullwerten blieb Inhalt; RFC 959 erklärte ausdrücklich, dass ein Loch keine Nullseite war.
  • Die Funktion entstand vor allem für TOPS-20 und NLS. RFC 1123 empfahl sie nicht allgemein, verlangte aber das gemeinsame Format, sobald Random-Access- oder löchrige Dateien es wirklich benötigten.

Ein fehlender Index war nicht zwingend ein Verlust

RFC 959 definierte Page Structure für diskontinuierliche, zufällig adressierbare oder „holey“ Dateien. Jede übertragene Seite trug einen Page Index. Dieser war ihre logische Nummer in der Datei und ausdrücklich keine Sequenznummer der Übertragung.

Auf dem Datenkanal direkt aufeinanderfolgende Seiten konnten folglich im Dateiplan eine Lücke lassen. Der TOPS-20-Anhang löst die entscheidende Zweideutigkeit: Leere Seitenplätze wurden nicht gesendet, und ein Loch war nicht dasselbe wie eine Seite aus Nullen.

Eine Nullseite existiert und belegt eine Position. Ein Loch besagt, dass an dieser Stelle keine Seite existiert. Ein lokales System kann beim Lesen in beiden Fällen Nullen liefern, ohne dass Zuweisung, Kosten, Attribute oder spätere Schreibvorgänge gleich wären. Das Füllen eines Lochs ist daher keine automatisch verlustfreie Reparatur.

Drei Parameter für drei Ebenen

FTP hielt TYPE, STRU und MODE auseinander. TYPE legte die logische Darstellung fest, STRU die Organisation der Datei und MODE die Übertragung auf dem Datenkanal.

File Structure war der Standard und betrachtete eine kontinuierliche Folge von Datenbytes. Record Structure bewahrte aufeinanderfolgende Datensätze. Page Structure bewahrte unabhängig indexierte Seiten.

Die Auswahl spiegelte verschiedene Hostsysteme. RFC 959 vergleicht festlängige Records auf IBM-Mainframes mit Zeichenströmen auf TOPS-20. Ohne Strukturangabe konnte ein Empfänger eine Quellgrenze nicht von seiner eigenen Speicherentscheidung unterscheiden.

Umwandlung war zulässig, sollte aber umkehrbar bleiben. Ein dateiorientierter Host durfte Records lokal nutzbar ablegen, musste sie bei Abruf mit derselben Struktur wiederherstellen können. RFC 1123 verlangte diese Invertierbarkeit soweit praktikabel.

Darum gehört der Parametersatz zur Evidenz eines Transfers. Gleiche Payloadbytes unter anderen Parametern müssen nicht dieselbe gespeicherte Struktur bedeuten.

Der Header erklärte die Null

Der minimale Seitenheader enthielt Header Length, Page Index, Data Length und Page Type. Jedes Feld war ein logisches Byte; dessen Breite bestimmte TYPE.

Der Seitentyp gab einer Datenlänge von null Kontext. Last Page schloss die Übertragung mit einem minimalen Header ohne Daten. Simple Page trug normale Seitendaten. Descriptor Page konnte die gesamte Datei beschreiben. Access Controlled Page ergänzte ein Feld mit seitenbezogener Kontrollinformation.

Ein nicht erschienener Index konnte also ein Loch sein. Ein erschienener Null-Daten-Header konnte das bestätigte Ende sein. Eine Descriptor Page galt dem Ganzen. Ein einzelner Längenwert reichte nicht zur Interpretation.

Auch Ankunft und Platzierung blieben getrennt. Wer nach Empfangszeit statt Page Index ordnete, konnte trotz vollständiger Übertragung eine andere Datei bauen.

Der konkrete TOPS-20-Fall

RFC 765 und RFC 959 nennen als Hauptgrund den effizienten Austausch zwischen TOPS-20-Systemen, besonders von NLS-Dateien.

Eine TOPS-20-Plattendatei bestand aus Pfad, Seitentabelle, einer möglicherweise leeren Seitenmenge und Attributen. Tabelleneinträge konnten EMPTY sein oder auf eine Seite zeigen; belegte Einträge konnten eigene Zugriffsbits tragen. Zu den Attributen gehörten Zeitangaben, logische Bytebreite, EOF-Zeiger, Zähler und Backupinformationen.

Die Tabelle musste nicht dicht sein. Leere Einträge durften zwischen vorhandenen Seiten liegen. Der EOF-Zeiger musste nicht auf das letzte Datum zeigen. NLS nutzte beide Sonderfälle.

Das dokumentierte Beispiel verwendete TYPE L 36, STRU P, MODE S. Ein logisches Feld entsprach einem 36-Bit-TOPS-20-Wort. Der Index bezeichnete den Platz im Seitenplan, eine Descriptor Page trug globale Angaben, eine Datenseite ihre Kontrollbits.

Andere Hosts sollten nicht TOPS-20 nachbauen. Sie erhielten ein gemeinsames Format, mit dem relevante Unterschiede den Übergang überleben konnten.

Loch, Nullseite, verkürzte Seite

Der Anhang erlaubte außerdem, abschließende Nullen innerhalb einer vorhandenen Seite durch eine kleinere Data Length auszulassen. So entstehen drei verschiedene Gründe für weniger übertragene Daten.

Beim Loch existiert keine Seite. Bei der Nullseite existiert sie mit Nullwerten. Bei der verkürzten Seite existiert sie, aber der übertragene Umfang endet früher nach einer bekannten Regel.

Ein Hash über verkettete Nutzdaten kann diese Dateipläne nicht immer unterscheiden. Für eine belastbare Rekonstruktion braucht es Indizes, Typen, Header- und Datenlängen, Deskriptoren, Kontrollfelder, Ende und Transformationsregel.

Die Standards versprechen nicht, dass jedes Ziel Löcher gleich materialisiert, ein Loch immer als Null liest oder fremde Seitenrechte durchsetzt. Die Repräsentation kann Unterschiede tragen; ihre lokale Wirkung benötigt eigene Evidenz.

Seltenheit erlaubte keine Privatsprache

RFC 1123 empfahl die allgemeine Implementierung der Seitenstruktur nicht. Sie war spezialisiert und sollte den interoperablen Mindestkern nicht unnötig vergrößern.

Brauchte ein Host FTP jedoch für Random-Access- oder löchrige Dateien, musste er das definierte Format verwenden, statt ein privates FTP-Format zu erfinden. Nichtunterstützung war möglich; inkompatible Neuerfindung unter demselben Protokoll nicht.

File Structure war verpflichtend. Record Structure war für Hosts mit entsprechender Dateisystemunterstützung verpflichtend. Page Structure blieb optional. Ein verpflichtender STRU-Befehl bedeutete nicht, dass jeder Argumentcode verfügbar war.

Der Registereintrag und die Maschine

RFC 5797 führte STRU als verpflichtenden Basisbefehl. Das IANA-Register für FTP-Befehle bewahrt die Beschreibung File Structure, die Parameterklasse und den Verweis auf RFC 959.

Das koordiniert Name und Rolle. Es belegt keine P-Unterstützung eines Servers, keine erfolgreiche Rekonstruktion, keine erhaltenen Kontrolldaten und keine heutige Verbreitung.

Ein Name im Register ist nicht automatisch eine Fähigkeit im System. Eine nicht gesendete Seite war ebenso wenig automatisch eine Nullseite in der Datei.

Die Bedeutung eines leeren Platzes

Auch moderne Schemas legen abwesend, null, unbekannt, verborgen und nicht anwendbar gern in dasselbe Feld. Die Datei bleibt lesbar und verliert ihre Herkunftssemantik.

STRU P hinterlässt eine nützliche Disziplin: Abwesenheit ausdrücklich darstellen, logische Position von Ankunft trennen, Rekonstruktionsmetadaten mitführen und Transformationen auf Rückkehr prüfen.

Die fehlende Seite wartete nicht auf Füllung. Ihr leerer Platz war Teil der Datei.

Quellen