Zusammenfassung

  • Nach RFC 1068 schrieb eine Bedienoberfläche die Parameter einer FTP-Operation in eine dauerhafte Warteschlange. Ein FTC-Daemon stellte später die Verbindungen zu zwei Servern her und wiederholte gescheiterte Versuche. submit machte den Auftrag haltbar, nicht die Zustellung.
  • Bei mehreren Dateien fror die erste erfolgreiche NLST-Liste den Umfang ein; ein Zeiger bewahrte Teilerfolge. Der Auftrag endete auch bei dauerhaftem Fehler oder ausgeschöpftem Versuchslimit, sodass nur der Status jeder einzelnen Datei das Ergebnis erklärte.

Die RFC 1068 beginnt mit einer Arbeit, die damals beim Menschen lag. FTP lief im Vordergrund. War ein Rechner nicht erreichbar oder brach die Verbindung ab, musste der Benutzer den Befehl erneut geben. Mit mehr Last, Verzögerung und Ausfällen wurde die anwesende Person selbst zu einer Voraussetzung der Wiederherstellung.

BFTP verlagerte diese Voraussetzung auf gespeicherten Zustand. Eine Oberfläche nahm den Wunsch entgegen; ein File Transfer Control Daemon, FTC, führte ihn später aus. Das Memo wollte eine Diskussion anstoßen und definierte ausdrücklich kein neues Protokoll. Es ergänzte bestehendes FTP um Warteschlange, Termin, Wiederholungen, Teilfortschritt und Benachrichtigung.

Der Eintrag beschrieb eine künftige Handlung

Quellrechner, Zielrechner und Steuerrechner durften verschieden sein. Der Benutzer lieferte Rechnernamen, Anmeldenamen, Kennwörter und Pfade beider Seiten. Er konnte kopieren oder verschieben, die Quelle löschen und am Ziel neu anlegen, ersetzen, anhängen oder einen eindeutigen Namen verlangen. FTP-Typ, -Modus und -Struktur waren wählbar. Platzhalter fassten mehrere Dateien zusammen; der erste Versuch konnte für später angesetzt werden.

Mit einer Mailbox für das Ergebnis und submit gelangte die Beschreibung in die Warteschlange. Danach durfte die Oberfläche verschwinden. Gesichert waren Parameter, Zeitplan und Kontaktadresse. Das bewies die Annahme eines Vorhabens. Es bewies weder erreichbare Server und gültige Zugangsdaten noch einen offenen Datenkanal oder eine vollständig geschriebene Zieldatei.

verify reduzierte einige Unsicherheiten, hob diese Grenze aber nicht auf. Wenn beide Server antworteten, konnte BFTP sich anmelden, Parameter prüfen und die Quelldatei finden. Bei einem ausgefallenen Rechner blieben Prüfungen offen. Selbst ein gutes Ergebnis lag vor einem gesonderten submit und einer späteren Übertragung. Es hielt eine Beobachtung fest; es reservierte keinen künftigen Zustand.

Der Steuerrechner lenkte Daten, die nicht durch ihn flossen

BFTP nutzte das Server-zu-Server-Modell der RFC 959. Der FTC-Daemon unterhielt je eine Steuerverbindung zur Quelle und zum Ziel. Er forderte mit PASV einen Endpunkt an, übergab ihn der anderen Seite mit PORT und kombinierte RETR mit STOR. Die Datenverbindung entstand direkt zwischen den FTP-Servern; die Dateibytes umgingen den Rechner mit der Warteschlange.

Damit entstanden getrennte Beweisspuren. Der Auftrag sagte, was beabsichtigt war. Die beiden Steuerdialoge zeigten angenommene und abgelehnte Befehle. Der Datenkanal trug den Inhalt. RFC 959 verlangte offene Steuerverbindungen während der Übertragung und eine abschließende Antwort 226 oder 250, bevor der nächste Transferbefehl folgte. Vorläufige Zustimmung, eine verbundene Buchse oder das Schließen des Datenkanals allein entschieden den Dateistatus nicht.

Das Verfahren traf außerdem auf uneinheitliche Server. Mindestens einer musste PASV unterstützen. RFC 1068 berichtet von ungewöhnlichen NLST-Ausgaben, fehlerhaften Antwortformaten und Implementierungen, die eine unterbrochene Verbindung als dauerhaftes 5xx statt als vorübergehendes 4xx meldeten. Ein Wiederholungsdienst handelt nach der Fehlersprache seiner Abhängigkeiten; eine falsche Klasse verändert seine Zukunft.

Zuverlässigkeit entstand zwischen mehreren Sitzungen

Nach einem vorübergehenden Fehler protokollierte FTC den Vorfall, wartete und begann mit neuen Verbindungen. Als Beispiel nennt das Memo ungefähr zehn Minuten am Anfang, danach verdoppelte Abstände und eine Obergrenze von etwa vier Stunden. Das war die Politik einer Implementierung, keine Zeitvorgabe für das Internet.

Die Familien 4yz und 5yz aus RFC 959 wurden damit zu Schaltentscheidungen. 4yz sagte, dass die Handlung nicht stattfand, derselbe Auftrag aber erneut versucht werden könne. 5yz sprach gegen unveränderte Wiederholung. Wurde ein Leitungsbruch als dauerhaft gemeldet, verlor ein heilbarer Auftrag seine nächste Chance. Die umgekehrte Verwechslung hielt einen aussichtslosen Auftrag am Leben.

Erfolg, ein dauerhafter Fehler oder die maximale Zahl von Versuchen beendeten den Ablauf. Anschließend verschickte der Daemon eine Mail. Deren Ankunft bestätigte einen Endzustand des Controllers, nicht automatisch eine gelungene Lieferung. Ob sie Erfolg oder Aufgabe meldete, stand erst im Inhalt.

Die erste brauchbare Liste setzte eine zeitliche Grenze

Ein Platzhalter bezeichnet kein stabiles Kollektiv, wenn sich das Quellverzeichnis während der Wartezeit ändert. Ein neues NLST bei jedem Versuch hätte später angelegte Dateien in einen alten Auftrag gezogen oder erwartete Mitglieder verloren. BFTP speicherte deshalb die Liste des ersten erfolgreichen NLST. Sie definierte den Umfang; spätere Neuzugänge blieben draußen.

Dieser feste Satz war dennoch keine atomare Transaktion. Waren vier Dateien erfolgreich und scheiterte die fünfte, entfernte BFTP die vier Zielkopien nicht, um von vorn zu beginnen. Ein Statuszeiger merkte sich erledigte Mitglieder; weitere Runden nahmen nur die offenen. Die Warteschlange vermied Wiederholung, trug dafür aber eine gemischte Geschichte aus Erfolg und Fehler.

„Complete“ hatte daher einen engeren und zugleich überraschenden Sinn. RFC 1068 erklärte den Auftrag für beendet, wenn alle Einzeltransfers gelangen, ein dauerhafter Fehler eintrat oder das Versuchslimit erreicht war. Das Wort bedeutete: Der Daemon plant keine weitere Arbeit. Es bedeutete nicht: Alle Dateien sind am Ziel. Die Mail listete jeden Dateistatus, weil erst diese Aufstellung den Ausgang zeigte.

Ein Suchwort war noch keine belastbare Identität

Bei der Abgabe hinterlegte der Benutzer ein Schlüsselwort, um Aufträge später zu finden und abzubrechen. Die Autoren nannten das selbst schwache Authentisierung. Wählten zwei Personen dasselbe Wort, konnte eine den Auftrag der anderen einsehen oder beenden. Eine Mail nach dem Abbruch machte die Handlung sichtbar, verlieh ihr aber nicht rückwirkend Berechtigung.

Für die Wahl eines fremden Datenziels wurde später eine weitere Grenze beschrieben. RFC 2577 zeigte, wie PORT beim Proxy-FTP einen Server zu einer Verbindung mit einem anderen Dienst veranlassen konnte – den Bounce-Angriff – und dass Gegenmaßnahmen die Proxy-Funktion einschränkten. Das ist kein Beleg für einen BFTP-Vorfall. Es zeigt nur, dass der nicht am Datenpfad liegende Controller dennoch wirksame Zielgewalt besaß.

Reichweite der historischen Aussage

RFC 1068 berichtet über einige Monate Nutzung am ISI, nicht über allgemeine Verbreitung. Sie beweist auch keine direkte Abstammung moderner Auftragswarteschlangen. RFC 959 liefert das FTP-Modell und die Antwortsemantik; RFC 2577 beschreibt später eine Sicherheitsgrenze. Keine der Quellen bestätigt eine bestimmte Dateiübertragung, sichere Kennwörter oder eine heutige Installation.

Der dauerhafte Befund ist präziser: Gespeicherte Absicht verbessert die Möglichkeit zur Wiederholung, erzeugt aber ein zweites Zustandssystem. Seine Einträge dürfen nicht mit dem befohlenen Ergebnis verwechselt werden. Die Warteschlange sagt, was versucht werden soll. Der Dateibericht sagt, was geschah.