Zusammenfassung

  • ETFTP bündelte viele packets in einem buffer und mehrere packets in einem burst, damit ein teurer Kanalzugriff viel Nutzlast trug; der Empfänger antwortete erst an der buffer-Grenze.
  • CONTROL_RESEND nannte fehlende packet-Nummern, CONTROL_OK akzeptierte den buffer. Zusammen mit NULL-ACK und der höchsten lückenlosen CONTROL-Sequenz blieben dies lokale Quittungen, keine Beweise für Dateiabschluss, Identität, Sicherheit oder Verlustursache.
  • Die Messwerte von 1993 gehörten zu einem 16-kbps-Punkt-zu-Punkt-Aufbau. Das RFC erklärte selbst, dass Passwortprüfung fehlte und Sicherheit beim Prototyp übersehen worden war.

Jede Antwort kaufte die Gegenrichtung neu

Die beschriebene taktische Satellitenstrecke benötigte vor dem Senden etwa 1,25 Sekunden für Funk- und Kryptosynchronisation. Die Satellitenlaufzeit addierte rund 500 Millisekunden zum Hin-und-zurück-Weg. Halbduplex bedeutete: Eine Antwort unterbrach die Datenrichtung und löste eine neue Synchronisationsphase aus.

ETFTP reduzierte diese Wechsel, indem es die Arbeit anders schnitt. Die Datei kam in buffers, jeder buffer in blocks, jeder block in ein DATA packet und mehrere packets in einen burst. LDATA markierte den letzten block eines buffers. War die Einheit vollständig, antwortete der Empfänger mit CONTROL_OK; bei Lücken enthielt CONTROL_RESEND buffer-Nummer, Anzahl und konkrete packet-Nummern.

Damit war auch die Beweisgröße definiert. Die RESEND-Liste zeigte die aktuelle Sicht des Empfängers auf einen buffer. OK schloss diese Einheit. Der gesamte Transfer brauchte weiterhin QUIT und DONE als gesonderten Abschluss.

Anpassung war eine Zustandsänderung, keine Ursachenanalyse

Ein größerer buffer sparte Quittungsgrenzen, belegte aber Speicher und den Kanal länger. Ein größerer burst hielt den Sender aktiv, konnte jedoch Zwischenpuffer belasten. Ein größeres packet senkte relativen Overhead, verlor bei einem Bitfehler aber mehr Inhalt.

Bei aktivierter Automatik und mindestens 50 Prozent erneut anzufordernden blocks verkleinerte die Implementierung zuerst packet size, danach burstsize und schließlich burstrate in Richtung der gemessenen tight-timer-Rate. Bei 99 Prozent Erfolg ohne Wiederholung durfte packet size steigen. Neue Werte wurden in CONTROL_OK angeboten; der Sender bestätigte gültige Änderungen mit NULL-ACK.

Das war ein enger gemeinsamer Zustand im Sinne der Minimum Initial Specification: Nummern, Fehlstellen, Werte und Umschaltgrenze. Doch die Quittung bewies nur Annahme. Erst die folgenden packets belegten, ob beide Enden den neuen Zustand am selben Übergang ausführten.

Lückenlos war nur das Präfix der Kontrollnachrichten

DATA und LDATA trugen die höchste lückenlos empfangene CONTROL-Sequenznummer. Sie bestätigte einen zusammenhängenden Anfang der Kontrollhistorie. Sie sagte nichts über spätere Nachrichten, noch unbekannte Datenlücken, die auf Platte geschriebene Datei oder den finalen Abschluss.

Auch Timer lieferten keinen Grund. Das Modell verwendete eingegebene baudrate- und radiodelay-Werte; wiederholte timeouts verlängerten das Warten linear um fünf Sekunden. Eine Auslösung zeigte eine verletzte Zeiterwartung, nicht automatisch Überlastung. BER, Medienkonkurrenz, Queue-Überlauf, schlechte Schätzung und Softwarelatenz konnten dasselbe Bild erzeugen. CONTROL_RESEND benannte das Fehlende, nicht dessen Ursache.

Running-Code Primacy trennt diese Ebenen sauber: Das Dokument bestimmt die Bedeutung einer Nachricht. Beobachtete Ausführung zeigt, ob die Implementierung die vereinbarte Grenze eingehalten hat.

Der Messstand war nicht das Internet

Die Tabellen nutzten eine 101.306-Byte-Datei, eine verschlüsselte 16-kbps-Strecke, zwei Sekunden radiodelay und mehrere buffer-, packet- und burst-Kombinationen. Die Funkgeräte waren per Koaxialkabel als „clean“-Verbindung mit BER 10e-5 gekoppelt. Der Spitzenwert von 10.432 bps entstand mit 131.072-Byte-buffer, 2.048-Byte-packets und sechzehn packets pro burst; Verbindungsaufbau, Reparatur und Abbau waren eingerechnet.

Das belegte einen Versuch, nicht Verbreitung, Multicast, Fairness in gemeinsamem Spektrum oder moderne Leistung. Der Text warnte, dass der maximale p-persistence-Wert der Punkt-zu-Punkt-Strecke bei mehreren Nutzern unpassend wäre. Zudem nannte er 16 bis 1.448 Bytes als einstellbaren packet-Bereich, während die Tabellen 2.048 Bytes verwendeten. Diese Spannung gehört zur Quelle.

Die Sicherheitsgrenze war ausdrücklich. ETFTP hatte keine Benutzer-/Passwortprüfung, wiederholte TFTP-Probleme und setzte im Experiment einen root-eigenen setuid-root-Server ein. Checksum, connection ID, Ports und Sequenzen ordneten Protokollzustand zu; sie authentifizierten keinen Benutzer und erteilten keine Dateiberechtigung.

RFC 1986 bleibt deshalb als Protokollbuchhaltung interessant. Lange Datenphasen sparten physische Wenden, eine kurze Liste reparierte nur die Löcher. Die Methode war stark, weil ihre Aussagen klein blieben: buffer angenommen, Transfer geschlossen, Ursache bestimmt und Gegenstelle vertraut waren vier getrennte Fragen.

Quellen