Zusammenfassung

  • LTP behandelt einen roten Blockpräfix mit Bestätigung und Wiederholung. Der anschließende grüne Suffix wird ohne beides übertragen. Die Farben beschreiben Behandlung, nicht Dringlichkeit.
  • Der Abschluss einer Sendesitzung belegt die Übertragung aller Bytes und den gemeldeten Empfang des roten Teils. Er belegt weder den vollständigen grünen Teil noch Bundle-Weiterleitung oder Annahme durch die Zielanwendung.

Ein Statuswort, drei verschiedene Garantien

Ist ein Block vollständig rot, schließt die Sitzung erst, wenn Empfangsberichte den ganzen Block abdecken. Ist er gemischt, gilt diese Bedingung nur für den Präfix. Ist er vollständig grün, kann der Abschluss ohne Datenbestätigung eintreten. Das gleiche Wort trägt also drei Beweisstärken, die allein von der vorab gewählten Rotlänge abhängen.

Die Spezifikation nennt zwei Voraussetzungen: Sämtliche Blockdaten wurden tatsächlich zur Übertragung gebracht, und die angesammelten Berichte weisen den vollständigen, nicht leeren roten Teil als empfangen aus. Der grüne Suffix fehlt bewusst in der zweiten Voraussetzung. Er kann vollständig, lückenhaft oder gar nicht angekommen sein.

RFC 5325 warnt vor einer falschen Semantik: Rot heißt nicht wichtiger oder eiliger. Der LTP-Client entscheidet, für welche Bytes Rückmeldung und Wiederholung den Aufwand rechtfertigen. Das können unverzichtbare Metadaten, der gesamte Inhalt oder gar keine Bytes sein.

Auch die ausgeführte Grenze ist relevant. Ein Segment enthält nur eine Farbe. Fällt die gewünschte Trennung in ein Segment, kann eine Implementierung dessen verbleibende Bytes rot behandeln. Dadurch wird der tatsächliche Garantieumfang größer als die abstrakte Vorgabe. EORP, EOB, Offsets und effektive Längen gehören deshalb in den Nachweis.

Nach Beginn des grünen Bereichs darf kein Rot mehr folgen. Widerspricht die Farbe eines Segments den bereits beobachteten Positionen, wird es als falsch eingefärbt verworfen und eine Aufhebung angestoßen. Die Präfix-Suffix-Form ist eine Protokollinvariante.

Welche Stelle weiß zu welchem Zeitpunkt was?

Der Abschluss der Erstübertragung ist ein senderseitiges Ereignis: Alle ursprünglichen roten und grünen Segmente wurden gesendet. Verlorene rote Segmente können weiterhin auf Wiederholung warten. Dieser Beleg schließt nur den ersten Durchlauf.

Der Empfang des roten Teils ist ein empfangsseitiges Ereignis. Sobald EORP die Rotlänge festlegt und alle roten Bytes vorliegen, erhält der lokale Client den Präfix und die Information, ob sein Ende zugleich EOB ist. Bei einem gemischten Block lautet die Antwort nein — ein entscheidender Teil des Belegs.

Für Grün gibt es Meldungen je Segment. Sie nennen Offset, Länge und gegebenenfalls EOB. Ein empfangenes EOB-Segment bestimmt das Ende, beweist aber keine lückenlose Folge davor.

Der Abschluss der Sendesitzung verbindet vollständige Übertragung mit bestätigtem Rot. Er macht keine zusätzliche Aussage über Grün. Eine Aufhebungsmeldung wiederum beschreibt einen Abbruch durch Gegenstelle, Fehler, Grenzwert oder Ressourcenknappheit. Bei senderseitiger Aufhebung besteht laut RFC keine Gewissheit, dass der Ziel-Client irgendeinen Teil erhalten hat.

Diese Ereignisse in einen einzigen Zustellstatus zu verwandeln, entfernt Akteur, Richtung und Gegenstand der Aussage.

Empfangsberichte sind räumlich begrenzt

Ein Checkpoint veranlasst einen Bericht. Der Bericht nennt Unter- und Obergrenze sowie empfangene Bereiche innerhalb dieses Fensters. Außerhalb des Fensters liegt keine negative Aussage vor. Wer nur positive Bereiche speichert, kann später „fehlte“ und „wurde nicht betrachtet“ nicht unterscheiden.

Ein großer Zustand kann mehrere eigenständige Berichte benötigen. Die rote Vollständigkeit ergibt sich aus der konsistenten Vereinigung passender Bereiche derselben Sitzung, nicht aus dem Vorhandensein eines beliebigen Berichts. Prozentwerte verlieren zudem die Lage einer Lücke und mögliche Widersprüche.

Die Berichtsbestätigung ist keine Datenbestätigung. Sie trägt die Seriennummer des beim Sender eingetroffenen Berichts und beendet dessen Wiederholung beim Empfänger. Objekt und Richtung des Empfangs sind umgekehrt zu einer Quittung für Nutzdaten. Ein bloßes Label „bestätigt“ ist daher unzureichend.

Zeitüberschreitungen werden von Kontaktwissen geformt

Die Betriebsumgebung teilt dem LTP-Motor mit, wann Senden in jede Richtung möglich ist, wie groß die einfache Lichtlaufzeit ist und welche Rate erwartet wird. Ein Timer beginnt nicht bei der Einreihung durch die Anwendung, sondern mit der tatsächlichen Übergabe eines Checkpoints oder Berichts an die Übertragung.

Kann die Gegenstelle bekanntermaßen nicht senden, werden einschlägige Timer angehalten und beim nächsten Kontakt fortgesetzt. Eine Zeitüberschreitung kann daher Verlust bedeuten, aber ebenso einen veralteten Kontaktplan, eine falsche Laufzeitschätzung, verspätete Queue-Signale oder eine normale Unterbrechung.

Die Stelle, die Plan und Signale kontrolliert, beeinflusst den Zeitpunkt der Fehlerentscheidung. Ein Bericht über angebliche entfernte Unzuverlässigkeit muss deshalb die lokale Plangeneration und Timerhistorie offenlegen.

Hinter dem LTP-Motor beginnt eine neue Beweiskette

Eine Engine-ID bezeichnet einen Motor in einem geschlossenen Kommunikationsverbund. Die Zuordnung zu Bundle-Endpunkten ist Sache des Adapters. Sie bezeichnet nicht automatisch eine Person, Organisation oder Zielanwendung.

Nach dem roten Empfang kann ein Bundle gespeichert bleiben, ablaufen, an einem späteren Hop scheitern, an einer Sicherheitsregel hängen oder nie konsumiert werden. Umgekehrt bedeutet eine gescheiterte LTP-Sitzung nicht zwingend endgültigen Verlust, wenn weitere Kopien, Kontakte oder Wege bestehen.

Die Sicherheitsmechanismen aus RFC 5327 ergänzen Herkunfts- und Integritätsschutz. Sie vergrößern keinen Berichtsbereich. Ein authentischer Bericht kann nur den roten Präfix abdecken; vollständiges Rot kann mit unvollständigem Grün zusammenfallen.

RFC 5326 ist als Experimental veröffentlicht. Der IESG-Hinweis besagt, dass Sicherheit, Überlastkontrolle und Wechselwirkung nicht wie bei einem Internetstandard geprüft wurden. Der Mechanismus enthält weder Fluss- noch Überlastkontrolle, ist nicht für den allgegenwärtigen öffentlichen Internetbetrieb bestimmt und begrenzt die damalige UDP-Nutzung auf Entwicklung oder private LANs. Spätere RFCs dokumentieren Register und Bundle-Fortschritt, nicht einen konkreten Einsatz.

Quellen und Beweisgrenze

Die Quellen belegen Semantik, Veröffentlichungsstatus und angrenzende Architektur. Sie belegen keinen aktuellen Einsatz, keinen Missionserfolg, kein vollständiges Grün, keine Bundle-Zustellung und keinen Anwendungsempfang.