Zusammenfassung

  • Der MTP-Master setzte eine Nachricht auf accepted, wenn er data[eom] und alle vorherigen Pakete gesehen hatte; unvollständige Nachrichten blieben pending oder wurden nach seiner Erreichbarkeitsbeurteilung rejected.
  • Ein rollender Zwölf-Nachrichten-Vektor verbreitete diese Zustände und durfte ein ungelöstes pending nicht aus dem Fenster schieben; neue Tokenbestätigungen mussten warten.
  • Erfolgreiche Konsumenten blieben im NAK-Verfahren gewöhnlich stumm. Transportannahme war weder positiver Einzelbeleg noch Anwendungsverarbeitung, Authentisierung oder Betriebsergebnis.

Ein zentrales Urteil über eine verteilte Beobachtung

MTP nannte die kooperierende Prozessmenge ein web. Ein Mitglied war zwingend der Master. Andere waren Produzenten und Konsumenten zugleich oder reine Konsumenten. Der Master bestimmte Mitgliedschaft, Leistungsparameter und Sendereihenfolge. Wer normale Nutzdaten senden wollte, benötigte ein Token mit einer vom Master vergebenen Nachrichtennummer.

Damit hatte der Master eine dokumentarische Macht: Er legte fest, welche Nachricht im gemeinsamen Protokoll als angenommen galt. Die Mitglieder erfuhren das Ergebnis aus späteren Paketen. Ihr individuelles Schweigen oder ihre lokale Beobachtung wurde nicht zu einer Abstimmung zusammengezählt.

Das war keine versteckte Schwäche, sondern das Modell. Eine spätere Auswertung muss deshalb die Frage benennen, die der Status beantwortet: Was entschied der Master im MTP-Web? Für die Frage, was jede Anwendung tat, fehlte ihm die Zuständigkeit.

RFC 1112 lieferte nur Best Effort

IP-Multicast nach RFC 1112 adressierte eine dynamische Hostgruppe. Datagramme erhielten dieselbe Best-Effort-Zuverlässigkeit wie gewöhnliches IP. Weder intakte Ankunft bei allen Gruppenmitgliedern noch relative Reihenfolge waren garantiert.

MTP setzte darüber eine Transportschicht. IP vervielfältigte Datagramme, während Token die Produzenten serialisierten und der Akzeptanzstatus eine gemeinsame Reihenfolge herstellte. Die Kundendaten selbst blieben für MTP uninterpretierten Oktette.

Gerade diese Schichtung macht den Begriff accepted eng. Vollständige Bytes beim entscheidenden Transportknoten können gleichzeitig mit einer Anwendungsablehnung bestehen. Das eine widerlegt das andere nicht.

Erfolg erzeugte absichtlich keinen ACK-Sturm

MTP war ein Negative-Acknowledgement-Protokoll. Ein Konsument meldete erkannte Lücken mit einem NAK. Wenn er keinen Fehler erkannte, sandte er dem Produzenten normalerweise keine positive Erfolgsbestätigung. Bei einer großen Gruppe sparte dieses Schweigen erheblichen Rückverkehr.

Schweigen war damit ein Verhalten unter Zeit-, Mitgliedschafts- und Retentionsannahmen. Es war kein dauerhaftes Rezept pro Empfänger. Es belegte nicht, dass eine Anwendung die Bytes parsierte, eine Operation zuließ, Zustand speicherte oder einem Menschen etwas anzeigte.

Ein Log, das „alle Empfänger bestätigt“ schreibt, erfindet genau die Nachrichten, die MTP vermied. Korrekt ist: Der Master entschied accepted; im beobachteten Intervall lagen bestimmte NAKs vor oder nicht vor; Anwendungsquittungen sind separat zu prüfen.

Accepted begann mit der Sicht des Masters

Die drei Regeln waren präzise. Sah der Master data[eom] und alle Zwischenpakete, wurde die Nachricht accepted. War sie unvollständig, der Produzent aber aus Sicht des Masters weiter funktionsfähig und verbunden, blieb sie pending. Bei unvollständiger Nachricht und vermutetem Ausfall oder einer Partition wurde sie rejected.

Der Status verband Beobachtung und Urteil. Paketvollständigkeit war eine Eingabe. Die angenommene Erreichbarkeit des Produzenten war eine Bewertung. Der später verteilte Vektor enthielt das Resultat, aber nicht automatisch alle Gründe. Für eine belastbare Rekonstruktion braucht man Empfangsbereiche, Endmarke, Zeit und Erreichbarkeitswechsel.

MTP musste den Inhalt nicht verstehen. Ein akzeptierter Bytestrom konnte eine ungültige, doppelte oder unbefugte Anwendungsanweisung enthalten. Das Protokoll garantierte keine semantische Wirkung.

Das zwölfte Feld verwandelte Unsicherheit in Backpressure

Der Akzeptanzdatensatz führte zwölf Zwei-Bit-Elemente mit accepted, pending und rejected. Mit jeder neuen Nachricht verschob sich das Fenster; ältere Endzustände verschwanden schließlich.

Ein pending durfte jedoch nicht über das Ende hinausrutschen. Drohte das, musste der Master neue token requests unbestätigt lassen, bis die älteste Nachricht angenommen oder verworfen war. Das System durfte seine offene Frage nicht durch Fortschritt aus dem Gedächtnis drücken.

Nach der endgültigen Entscheidung konnte der Eintrag später trotzdem aus dem Fenster fallen. Der Vektor war flüchtiger Koordinationszustand, kein Archiv. Wer langjährige Nachweise benötigt, muss Urteil, Inputs und Verantwortlichen in einem anderen Speicher festhalten.

Die 16-Bit-Nachrichtennummern wurden vom Master initialisiert und bei jeder Tokenvergabe erhöht. Eine vergebene Nummer war verbraucht und verlangte einen Endzustand. Sie bezeichnete Ordnung in einer Transportinstanz, keine unveränderliche Geschäftsidentität.

Eine doppelte Tokenbestätigung ließ mehrere Vergangenheiten offen

Kontrollpakete verbrauchten keine normalen Sequenznummern. Eine wiederholte token request konnte deshalb neu sein oder eine Wiederholung nach verlorener Bestätigung. Vielleicht hatte der Produzent Daten gesendet, die der Master vollständig verfehlte. Vielleicht überholte die Wiederholung eine verspätete Bestätigung.

RFC 1301 schrieb keine Gewissheit vor, sondern ein Verhalten. Betrachtete der Master das Token noch als pending, konnte er es erneut zuweisen. Der Produzent deutete ein doppeltes token confirm als NAK und sendete die früheren Daten derselben Nachrichtennummer neu. Brauchte er das Token nicht mehr, gab er es mit empty[cancel] zurück.

Die Wiederholung führte den Zustand zusammen, bewies aber nicht, welche der Hypothesen stimmte. Ein Audit muss Anfrage, Bestätigung, ursprüngliche Sendung, Mastersicht und Retransmission getrennt erhalten.

Retention begrenzte die Reparatur

heartbeat gab den Takt vor. window begrenzte neue und erneut gesendete Datenpakete eines Produzenten pro Herzschlag. retention bestimmte, wie lange er Daten und Wiederherstellungszustand aufbewahren musste.

Fehlten volle Nutzdatenpakete vor dem Nachrichtenende, hielt empty[dally] die Synchronisierung. Kurze Nachrichten wurden bis zu mindestens retention Paketen mit leeren Paketen ergänzt. Dadurch stieg die Chance, dass ein Konsument wenigstens ein Paket sah und den Produzenten erkannte. Eine Wahrscheinlichkeit wurde verbessert; universelle Zustellung wurde nicht attestiert.

Sequenzsprünge oder ein unvollständiges Fragment mit anschließendem Schweigen lösten einen unicast NAK aus. Der Produzent multicastete die fehlenden Bereiche an das ganze Web. Retransmissionen verbrauchten das Fenster, hatten Vorrang vor neuen Daten und erzeugten Duplikate bei unbetroffenen Konsumenten. Diese mussten sie verwerfen.

War der Inhalt nicht mehr reteniert, folgte nak[deny]. Der Empfänger meldete den Fehler seinem Client und konnte austreten. Nach Ablauf der Reparaturfrist blieb ein expliziter Fehler, aber keine Möglichkeit, fehlende Anwendungsbelege zu erzeugen.

Transportkennung blieb von Identität getrennt

MTP über IP verlangte RFC-1112-Level-2, nutzte die permanente Gruppe 224.0.1.9 und einen Bridge-Header mit Ports, Länge und optionaler Prüfsumme unter IP-Protokollnummer 92. TSAPs und Verbindungskennungen adressierten Instanzen.

Sie authentisierten niemanden. RFC 1301 diskutierte Sicherheit ausdrücklich nicht. Mitgliedschaft, Masterrolle und Tokenbesitz sind Protokollzustände; Identität und administrative Autorisierung benötigen eigene Nachweise.

RFC 1458 bewertete den Preis des Masters

RFC 1458 untersuchte MTP für große Bildübertragungen. Es würdigte Tokenordnung, Flusskontrolle, selektive NAK-Reparatur und Duplikatbehandlung, kritisierte aber externe Adress- und Kennungsabhängigkeiten sowie Verzögerung und Stau durch fast vollständig masterzentrierten Kontrollverkehr. Für jene Last erschien MTP ungeeignet.

Das war eine Designbewertung, kein Beleg einer konkreten Übertragung. Protokollkorrektheit, Skalierung der Kontrollinstanz und Anwendungserfolg blieben getrennte Fragen.

Quellen

Die Quellen belegen historische Regeln und eine spätere Bewertung, nicht ein reales MTP-Web, Empfängerzahlen, authentisierte Mitglieder, Anwendungsverarbeitung, Vorfall, Nutzung oder heutiges Ergebnis.