Zusammenfassung

  • Der ursprüngliche FTP-Neustart setzte Marken in Block- oder Kompressionsrahmen und verband mit 110 MARK eine Senderposition mit einem nach stabiler Speicherung erzeugten Empfängerzustand.
  • Beide Werte blieben systemeigen. Der Empfänger konnte darin Transformationszustand festhalten, etwa ein bereits verarbeitetes CR vor dem noch ausstehenden LF.
  • RFC 3659 definierte REST STREAM später als Anzahl der im unmittelbar folgenden Transfer auszulassenden Oktette. Der Offset bewies weder Dateiversion noch Teilkopie oder Endergebnis.

Zwei Verbindungen trennten Fortschritt und Beleg

FTP führt Befehle und nummerierte Antworten über eine Steuerverbindung; die Datei reist über eine eigene Datenverbindung. Diese Trennung erlaubte es dem Empfänger, einen Wiederaufnahmepunkt zu melden, ohne den Datenstrom anzuhalten.

RFC 1123 berichtigt die Bedeutung der 110-Antwort. ssss war eine im Datenstrom erschienene Zeichenfolge und codierte eine Position im Dateisystem des Senders. rrrr codierte die entsprechende Position beim Empfänger. Jeder Wert wurde von demselben System erzeugt und später wieder ausgelegt.

Das Gleichheitszeichen behauptete keine numerische Identität. Es sagte nur, dass zwei lokale Zustände an derselben Übertragungsgrenze zusammengehörten. Der steuernde Client musste diese Beziehung bewahren und jedem Endpunkt dessen eigenen Wert zurückgeben.

Der Sender durfte nicht auf jede 110-Antwort warten. Antworten mussten nicht synchron mit den Daten eintreffen. Eine sichtbare Fortschrittsanzeige konnte weiter sein als der letzte belastbare Kontrollpunkt. Bewegte Daten und rekonstruierbarer Zustand waren verschiedene Größen.

Nur ein gerahmter Modus konnte Marken tragen

RFC 959 trennt Darstellungstyp, Dateistruktur und Übertragungsmodus. STREAM übermittelt eine Folge und zeigt EOF gewöhnlich durch Schließen der Datenverbindung. Der Text nennt diese Grenze für sich unzuverlässig, weil ein vorzeitiger Abbruch gleich aussehen kann.

Im Blockmodus begann jede Einheit mit einem Drei-Oktett-Kopf: acht Bit Deskriptor, sechzehn Bit Längenangabe. Deskriptorwert 16 kennzeichnete eine Neustartmarke. Es folgte eine druckbare Zeichenfolge ohne Leerzeichen, eingebettet in die FTP-Darstellung und getrennt von den Nutzdaten.

Die Marke war weder eine umgedeutete TCP-Sequenznummer noch ein reserviertes Zeichen im Dokument. Sie gehörte zur Anwendungsschicht. Block- und komprimierter Modus konnten außerdem das Dateiende ohne Verbindungsabbau ausdrücken und damit den historischen Neustartmechanismus transportieren.

Ein Paketmitschnitt konnte zwar Leitungsfortschritt zeigen, nicht aber die Stelle, ab der der Sender seine Darstellung neu erzeugen oder der Empfänger seine gespeicherte Darstellung fortsetzen konnte. Dieser Zustand lag bei den FTP-Prozessen.

Erst festschreiben, dann den Empfängerwert bilden

RFC 1123 verlangt, dass ein Empfänger beim Eintreffen einer Marke alle vorherigen Daten in stabilen Speicher zwingt, bevor er rrrr codiert. Die Antwort bedeutete damit nicht bloß „bis hier gelesen“, sondern „bis hier kann mein System nach der angenommenen Störung zurückkehren“.

Stabil war keine Zusage ewiger Aufbewahrung oder standortübergreifender Replikation. Der Standard bestimmte kein Speichermedium. Er band die Wahrhaftigkeit der Marke an das System, das sie ausstellte und später wieder verstehen musste.

Auch der User-FTP sollte die Paare dauerhaft halten. RFC 1123 empfiehlt eine leere Kontroll-Datei beim Start, das Anhängen vollständiger Paare und ihre Löschung nach erfolgreichem Abschluss. Nach einem Absturz galt das letzte vollständige Paar, nicht der höchste flüchtige Zähler.

Die Löschung gehörte zum Vertrag. Eine alte Marke ohne Herkunft, Richtung, Parameter und Ablauf kann in einem späteren gleichnamigen Transfer gefährlich plausibel wirken.

Eine Position konnte mitten in einer Zeichenumwandlung liegen

Das anschaulichste Beispiel betrifft CRLF. Bei TYPE ASCII kommt der Zeilenwechsel im Netz als CRLF an, während ein Zielsystem nur LF speichert. Fällt eine Marke zwischen beide Zeichen, hat der Empfänger CR bereits erkannt und verworfen, LF aber noch nicht in die lokale Darstellung überführt.

rrrr muss dann außer der Dateiposition auch „CR bereits gesehen“ enthalten. Ein nackter Plattenoffset könnte den Zeilenwechsel verdoppeln oder beschädigen. Wiederaufnahmeposition bedeutete Position plus Zustand der Transformation.

FTP sollte Zeichencodes, Wortlängen, logische Bytegrößen und Speichermodelle verschiedener Rechner verbinden. Die gemeinsame Netzrepräsentation machte Übertragung möglich, nicht interne Dateien identisch. Opaque Marken waren gerade deshalb präzise: Nur der jeweilige Besitzer musste sie verstehen.

Die Undurchsichtigkeit setzte eine Zuständigkeitsgrenze. Der Sender interpretierte den Senderwert, der Empfänger den Empfängerwert, und das Protokoll hielt nur die nachgewiesene Zuordnung zusammen.

Die Richtung entschied über die Rückgabe

Beim Hochladen setzte die Nutzerseite ssss in den Strom. Der Server schrieb den Präfix fest, erzeugte rrrr und meldete das Paar. Zur Fortsetzung stellte der Client sich mit ssss zurück und schickte dem Server REST rrrr.

Beim Abruf setzte der Server die Strommarke. Der Client machte seine Teilkopie haltbar und hielt seinen lokalen Zustand fest. Später stellte er diesen wieder her und gab dem Server dessen ursprüngliche Marke zurück.

FTP behandelte sogar den Transfer zwischen zwei Servern unter Kontrolle eines Nutzerprozesses. Der Koordinator verwahrte zwei fremde Koordinaten, ohne beide Dateisysteme zu verstehen. Jeder Endpunkt erhielt nur den Wert, den er selbst erzeugt hatte.

Der Koordinator besaß die Zuordnung, nicht die Auslegung. Daraus folgte eine Pflicht: Paare unterschiedlicher Dateien, Sitzungen oder Richtungen durften nicht vermischt werden.

REST speicherte einen Parameter für den nächsten Schritt

Eine 350-Antwort übertrug keine Datei. Sie sagte, dass der Server einen Neustartparameter gespeichert hatte und einen Dienstbefehl erwartete. Weder neue Daten noch Integrität oder Fertigstellung waren damit belegt.

Im Zustandsmodell von RFC 959 folgten RETR, STOR oder unter Umständen APPE. RFC 1123 unterscheidet 554 für eine nicht anwendbare Position und 555 für eine Abweichung von TYPE oder STRU gegenüber der vorhandenen Datei. Koordinate und Darstellung konnten unabhängig scheitern.

Zwischen den zwei Befehlen blieb Absicht im Server zurück. Scheiterte der Client vor dem geplanten Transferbefehl, konnte ein späterer Vorgang den alten Zustand erben. Die STREAM-Erweiterung machte die unmittelbare Reihenfolge deshalb verbindlich.

REST STREAM reduzierte den häufigen Fall auf Oktette

RFC 3659 definiert Wiederaufnahme im STREAM-Modus ohne Marken im Datenstrom. Das REST-Argument wurde zur Dezimalzahl: So viele Oktette sendet der unmittelbar folgende Transfer nicht. REST 0 hebt die Auslassung auf und verlangt die ganze Datei.

Das Beispiel setzt TYPE I, prüft, dass sich die Serverdatei nicht geändert hat, sendet REST 802816, erhält 350 und lässt RETR direkt folgen. Für binäre Oktettfolgen ist das die vertraute Offset-Idee.

Der Wert enthält jedoch keinen Konvertierungszustand, keine Versionsidentität und keinen Beleg für den beim Client liegenden Präfix. Er beschreibt nur die Auslassung im nächsten Transfer.

REST muss dessen letzter vorausgehender Befehl sein. Kann der Transferbefehl nicht gesendet werden, soll der Client REST wiederholen. Soll kein Neustart stattfinden, soll er REST 0 senden. Eine syntaktisch gültige Zahl kann erst bei RETR oder STOR als unbrauchbar erkannt werden, wenn Objekt und Operation feststehen.

Bei STOR wurde der Offset zu Schreibmacht

Nach RETR entscheidet der Client, wie er den neuen Suffix mit seiner Teilkopie verbindet. Bei STOR schreibt der Server in ein vorhandenes Teilobjekt. Ein falscher Offset kann entfernte Daten kombinieren oder überschreiben.

RFC 3659 bestimmt REST mit STOR nur für den Abschluss eines zuvor gescheiterten Transfers. Liegt die Marke nicht am aktuellen Ende der gespeicherten Daten, ist das Ergebnis undefiniert. Dasselbe gilt, wenn die Fortsetzung das Ziel nicht wenigstens wieder auf seine vorherige Größe erweitert. Erlaubtes APPE muss nach REST wie STOR an der gewählten Position wirken, nicht blind anhängen.

Damit wird REST nicht zu einem allgemeinen Ferneditor. Transaktionssicherheit entsteht aber ebenfalls nicht. Eine weitere Unterbrechung lässt einen neuen Teilzustand zurück. Benennung, Sichtbarkeit, Rechte, Ersetzung und Bereinigung bleiben lokale Entscheidungen.

Die Fähigkeit, eine Schreibposition anzuwenden, ist keine Berechtigung, das Objekt zu verändern.

Der richtige Offset konnte zur falschen Version gehören

RFC 3659 empfiehlt, vor dem ersten RETR die Änderungszeit zu erfassen und vor der Fortsetzung zu vergleichen. Bei STOR kann der Client die Quelle mit dem entfernten Teil vergleichen. MLST-Fakten können weitere Hinweise liefern.

Der Standard macht daraus keinen Identitätsbeweis. Uhren können abweichen; ein Zeitwert kann sich ohne endgültige Inhaltsänderung ändern; Inhalt kann geändert und wiederhergestellt werden. Änderungsdaten sind Signale zur Ungültigkeit, keine kryptografischen Fingerabdrücke.

SIZE beschreibt die Übertragungsgröße unter dem aktuellen TYPE. Zwei verschiedene Dateien können gleich groß sein. Das Erreichen der erwarteten Länge beweist nicht, dass Präfix und Suffix aus derselben Version stammen.

Wo Integrität zählt, muss nach der Fortsetzung das gesamte Ergebnis geprüft werden. Erfolgreiche FTP-Antworten bestätigen den Ablauf, nicht die Gleichheit des rekonstruierten Inhalts.

FEAT meldete eine Grammatik, keine Datei

Ein Server mit dem RFC-3659-Verhalten meldet exakt REST STREAM über FEAT. Der Client kann so den Dezimaloffset von Neustartunterstützung unterscheiden, die nur Block oder Kompression betrifft.

Das IANA-Register der FTP-Befehle und -Erweiterungen führt Basis-REST und das geänderte REST+ für STREAM getrennt. Das Register dokumentiert Standardisierung und Konformitätsklasse, nicht heutige Verbreitung oder Implementierungsqualität.

FEAT beantwortet, welche Form ein Server zu verstehen erklärt. Es beantwortet nicht, ob die Datei unverändert blieb, das Teilstück stimmt, das Konto schreiben darf oder das Ergebnis korrekt ist.

Ein Kontrollpunkt durfte nie mächtiger werden als das Ergebnis

Das historische Verfahren bewahrte mehr lokale Bedeutung und brauchte dafür Rahmen, Marken, asynchrone Antworten und eine Nebenakte. STREAM wählte eine verbreitete Koordinate und verlagerte Versionsprüfung und Endkontrolle nach außen.

Beide Verfahren gaben dem Kontrollpunkt eine begrenzte Rolle: Er nannte einen möglichen Fortsetzungsort. Er authentisierte weder Quelle noch Inhalt und erlaubte keine spätere Ausführung. Seine Gültigkeit musste mit Objekt, Darstellung und Recht enden können.

Wiederaufnahme spart Wiederholung, erzeugt aber verwalteten Zwischenzustand. Lebt ein Offset länger als die Version, die er beschrieb, wird Bequemlichkeit zur unbemerkten Verbindung zweier Epochen.

Quellen und Beweisgrenzen

Die geschlossenen Quellen belegen die spezifizierten Mechanismen und ihre Entwicklung. Sie messen weder heutige Unterstützung noch Einsatz, Erfolgsquote oder Integrität eines konkreten Transfers. IANA-Eintrag und FEAT-Zeile beweisen keine sichere Wiederaufnahme.