Zusammenfassung

  • Die frühere TFTP-Regel erlaubte beiden Seiten, nach einem alten Duplikat ihr aktuelles Datagramm erneut zu senden; ein verzögertes ACK konnte dadurch alle späteren DATA- und ACK-Pakete in Paare verwandeln.
  • RFC 1123 verbot dem DATA-Sender, den aktuellen Block allein wegen eines duplizierten ACK erneut zu senden; RFC 1350 von Karen Sollins übernahm die Korrektur und nennt Noel Chiappa ausdrücklich als Urheber der Fehlerbehebung vom Mai 1992.

Der als „Sorcerer’s Apprentice Syndrome“ bezeichnete Fehler begann nicht mit beschädigten Daten. Er begann mit einem echten ACK, das lediglich zu spät kam. Sender A hatte den zugehörigen Block wegen eines Timeouts bereits wiederholt. Empfänger B bestätigte auch die Wiederholung. Nun waren zwei gültige Bestätigungen unterwegs, die A in zwei unterschiedlichen Zuständen erreichten.

RFC 1123 beschreibt die Folge Paket für Paket. A sendet DATA X. B antwortet mit ACK X, doch dieses ACK bleibt im Netz liegen. A läuft in den Timeout und wiederholt DATA X. B erkennt das Duplikat und sendet ein zweites ACK X.

Das erste ACK erreicht A, worauf A zu DATA X+1 fortschreitet. Dann trifft das zweite ACK X ein. Nach der fehlerhaften Regel durfte A auf ein altes Duplikat mit seinem „aktuellen“ Datagramm reagieren. Aktuell ist inzwischen DATA X+1, also geht davon eine zweite Kopie ab. B bestätigt beide Exemplare. Das erste ACK X+1 führt zu X+2, das zweite verdoppelt X+2. So läuft der Rest des Transfers paarweise weiter, sofern nicht ein passend gelegener Verlust den Takt unterbricht.

Der Inhalt kann trotzdem stimmen, weil doppelte Blocknummern erkennbar sind. Betriebsseitig ist der Transfer dennoch kaputt. Übermäßige Wiederholungen können ihn in einen Timeout treiben. War Stau der Grund für das erste verspätete ACK, erzeugen die Duplikate zusätzliche Last an genau derselben Engstelle. Eine lokale Vorsichtsmaßnahme verstärkt damit die Bedingung, vor der sie schützen soll.

Der Sender verlor nur eine bestimmte Befugnis

Die Korrektur in RFC 1123 ist enger als ein allgemeines Wiederholungsverbot. Die DATA erzeugende Seite darf ihren aktuellen DATA-Block niemals allein deshalb erneut senden, weil ein dupliziertes ACK eingetroffen ist. Einen Wiederholungstimer braucht sie weiterhin. Bleibt das erwartete ACK aus, darf der noch offene Block nach Ablauf der Zeit neu gesendet werden.

Der Empfänger darf seinerseits auf doppeltes DATA mit einem weiteren ACK antworten. Das ist sinnvoll, wenn die erste Bestätigung wirklich verloren ging. Ist der Sender jedoch schon weiter, muss das alte ACK folgenlos bleiben. Die Korrektur trennt damit die Wiederholung einer Information von der Erzeugung neuer Arbeit.

RFC 1123 verlangt zusätzlich adaptive Timeouts und mindestens exponentielles Backoff. Beides vermindert verfrühte Wiederholungen und nimmt bei Störungen Druck vom Pfad. Es ersetzt die Zustandsprüfung nicht. Ein besserer Timer kann die Schleife seltener auslösen; nur die Regel für alte ACKs macht sie unschädlich.

Diese Asymmetrie reicht über TFTP hinaus. Ein Baustein kann eine doppelte Eingabe idempotent verarbeiten, während seine doppelte Antwort beim Nachbarn einen nicht idempotenten Vorgang auslöst. Protokolltests müssen deshalb den geschlossenen Kreis untersuchen, sobald die beiden Seiten nicht mehr denselben Gesprächsstand haben.

„Trivial“ beschrieb einen kleinen Funktionsumfang

RFC 1350 nennt TFTP bewusst ein sehr einfaches Dateiübertragungsprotokoll. Es kann Dateien lesen und schreiben, aber keine Verzeichnisse auflisten und bietet im Grundprotokoll keine Benutzeranmeldung. Diese Beschränkung war kein Urteil über die Wichtigkeit seiner Aufgabe.

RFC 1123 charakterisiert den Grundbetrieb als Stop-and-Wait mit einem effektiven Fenster von einem 512-Oktett-Segment. RFC 906 schlug TFTP für das Laden beim Systemstart vor: Ein kleiner Client konnte in ROM oder EPROM liegen, das erste Programm holen und dann an reichhaltigere Software übergeben. In dieser Phase war eine leicht implementierbare Brücke wichtiger als die volle Ausnutzung einer schnellen Strecke.

Gerade eingebettete Einfachheit kann lange nachwirken. Firmware-Code ist schwerer zu finden und zu ersetzen als eine gewöhnliche Anwendung. Eine missverständliche Erlaubnis aus einer Spezifikation kann über Hersteller und Gerätegenerationen kopiert werden. Interoperabilität hält Fehler ebenso zuverlässig am Leben wie Funktionen, wenn die Zustände nicht präzise beschrieben sind.

Spätere RFCs ergänzten Optionsaushandlung, Blockgrößen und Zeitparameter. RFC 2347 führte dafür ein eigenes OACK-Paket ein und verlangte, nicht unterstützte Optionen wegzulassen, statt ihre Bedeutung stillschweigend zu verändern. Erweiterungen dürfen die grundlegende Duplikatregel weder im erfolgreichen Aushandlungspfad noch beim Rückfall auf das Basisprotokoll aufheben.

Auch sicherheitlich bleibt eine Grenze. RFC 1350 vermerkt die fehlende Authentisierung. RFC 1123 empfiehlt konfigurierbare Pfadbeschränkungen und das lautlose Ignorieren von Broadcast-Anfragen. Ein minimales Werkzeug kann in einem abgeschotteten Bootnetz angemessen und als offen erreichbarer Dateidienst ungeeignet sein.

Sollins’ Autorenschaft macht die Zusammenarbeit sichtbar

Karen Sollins ist als Autorin von RFC 783 aus dem Jahr 1981 und RFC 1350 aus dem Jahr 1992 genannt. RFC 1350 schreibt die ursprüngliche Konstruktion Noel Chiappa zu und die Überarbeitung Chiappa, Bob Baldwin und Dave Clark, mit Kommentaren von Steve Szymanski. Es führt weitere Beteiligte auf und erklärt ausdrücklich, dass Chiappa im Mai 1992 den Sorcerer’s-Apprentice-Fehler sowie kleinere Dokumentprobleme korrigierte.

Sollins allein als Erfinderin oder Fehlerfinderin darzustellen, würde diese Herkunft auslöschen. Ihre Leistung liegt in der fortgesetzten Protokollautorenschaft: die Grenzen eines absichtlich kleinen Systems zu bewahren, Entscheidungen zu erläutern, Implementierungserfahrung aufzunehmen und Rollen so zu dokumentieren, dass eine korrigierte Regel zum gemeinsamen Standard werden kann. Der von Robert Braden herausgegebene RFC 1123 ergänzte die detaillierte Ablaufbeschreibung und machte die Korrektur zur Hostanforderung.

Die öffentliche Biografie des MIT CSAIL ordnet Sollins in eine breitere Arbeit an netzbasierten Systemen, verteilter Namensverwaltung, Authentisierung, globaler Benennung, extrem langlebigen Informationssystemen und Skalierung ein. Sie studierte Mathematik am Swarthmore College, erwarb Master und Doktorgrad in Informatik am MIT und war 1999 sowie 2000 leitende Programmdirektorin für Netzwerkforschung bei der US-amerikanischen National Science Foundation.

In diesen Themen kehrt dieselbe Frage wieder: Wie behält eine Nachricht ihre Bedeutung, wenn Zeit und Zustand auseinanderlaufen? Das verspätete ACK ist echt. Es bezieht sich aber auf einen abgeschlossenen Block und ist kein Befehl für den aktuellen.

Die dokumentierte Arbeitsteilung schützt zukünftige Wartung. Wer Jahrzehnte später einen Bootclient neu schreibt, könnte das Ignorieren doppelter ACKs als überflüssige Altlast ansehen. Die überlieferte Fehlerschleife erklärt, warum die Bedingung existiert und welche Last zurückkehrt, wenn sie entfernt wird.

Ein korrekter Datei-Hash reicht nicht

Ein aussagekräftiger Test verzögert ACK X bis nach der Wiederholung von DATA X und liefert anschließend beide ACKs an den bereits fortgeschrittenen Sender. DATA X+1 darf nur einmal erscheinen. Ergänzend sind echter Verlust, Umordnung, DATA-Duplikate, Blocknummerngrenzen sowie erfolgreiche und abgelehnte Optionsaushandlungen zu prüfen.

Gespeichert werden sollten Datagramme je Block, Laufzeit, Timerverlauf und Zustandswechsel, nicht nur der Hash der empfangenen Datei. Bei geschlossenen oder alten Geräten kann eine reproduzierbare Paketaufzeichnung zusammen mit exakter Firmwareversion und Prüfsumme der belastbarste Nachweis sein.

Wo TFTP heute noch aktiv ist, muss vor Ort geklärt werden. Manche Systeme nutzen es nur in Fertigung, Netzstart oder Notfallwiederherstellung, andere gar nicht mehr. Wo es bleibt, lässt sich Sollins’ dokumentierte Grenze direkt testen: Beschreibt die zurückkehrende alte Nachricht nur vergangene Arbeit, oder darf sie aktuelle Arbeit erneut erzeugen?

Quellen