Zusammenfassung

  • Auf Objekt 418 folgt 420: Das belegt eine beobachtete Nummernlücke, aber weder Netzverlust noch die Nichterzeugung von 419.
  • Der aktuelle MOQT-Entwurf unterscheidet dauerhaftes Nichtvorhandensein, unbekannten Zustand und ein ausgeschöpftes Relay-Wartebudget. Telemetrie sollte diese Belege nicht vermischen.

Der Zähler springt von 418 auf 420. Das Monitoring verbucht Objekt 419 als Verlust. draft-ietf-moq-transport-21 verlangt eine vorsichtigere Aussage.

MOQT liefert Objekte über Streams oder Datagramme, unmittelbar oder über Relays, per Subscription oder begrenztem FETCH. 419 könnte noch nicht produziert, auf diesem Pfad ausgefiltert, upstream angefordert, nach Ablauf eines Wartebudgets aufgegeben oder vom Original Publisher dauerhaft ausgeschlossen worden sein. Ähnliche Lücken haben verschiedene Urheber.

Die Lücke bewahrt das Unbekannte

Revision 21 vom 8. September übernimmt das bereits in Revision 20 enthaltene Drei-Zustände-Modell. Für Subscriber und Cache ist ein Objekt als vorhanden bekannt, als nicht vorhanden bekannt oder unbekannt, weil es noch nicht eingetroffen oder erzeugt worden ist. Revision 21 ordnet vor allem das Dokument neu; sie hat dieses Modell nicht eingeführt.

Die Regel ist eng: Eine beobachtete Object-ID-Lücke verrät allein nichts über die übersprungenen Nummern. Subgroups können verschiedene Streams nutzen, Datagramme können überholen, ein Relay kann beide Ränder zwischenspeichern und die Mitte upstream suchen, ein Filter kann Teile auslassen.

Ein sauberer Beleg nennt Track, Group, Object, Subgroup, Lieferweg, Beobachter und Zeitpunkt. „Hier bis zu diesem Termin nicht gesehen“ ist eine Beobachtung. „Wird nie existieren“ braucht zusätzliche Autorität.

Wer „nie“ sagen darf

Prior Object ID Gap erklärt einen vorherigen Bereich für nicht existent und dauerhaft ausgeschlossen. Nur der Original Publisher darf die Eigenschaft hinzufügen; Relays dürfen sie nicht erfinden. Ein Relay darf sie nur entfernen, wenn ein FETCH dieselbe Lücke bereits ausdrückt. Prior Group ID Gap wendet das Prinzip auf ganze Gruppen an.

Auch ein abgeschlossener, begrenzter FETCH kann Bereichszustände kommunizieren. Das Format hat jedoch drei Marker: End of Non-Existent Range, End of Unknown Range und End of Timed-Out Range. Der Publisher verantwortet die dauerhafte Erzeugungsaussage, das Relay seine Verwahrung und Warteentscheidung, der Subscriber sein Budget.

Timeout ist ein Budgetbeleg

Die relevante jüngere Änderung im aktuellen Entwurf ist der in Revision 20 ergänzte Timed-Out-Bereich. Mit 0x20C werden Objekte, auf die ein Relay nach Ablauf von FILL_TIMEOUT nicht weiter wartet, von wirklich unbekannten Objekten getrennt.

Der Timeout ist ein Gesamtbudget in Millisekunden für die upstream ausgelösten FETCHes einer Anfrage. Null verlangt nur sofort Verfügbares. Ohne Parameter gilt eine implementierungsspezifische Dauer. Ein Relay darf den gewünschten Wert sogar ohne Mitteilung verkürzen.

Timed-Out bedeutet daher: Dieses Relay wartete für diese Anfrage unter diesem Budget nicht länger. Es beweist weder Paketverlust noch Nichterzeugung, und ein anderer Pfad kann später liefern. Der Entwurf erlaubt, dass ein Objekt nach einer Nichtvorhandensein-Aufzeichnung aus einer anderen Quelle eintrifft, ohne den Track automatisch als fehlerhaft zu erklären. Caches brauchen Herkunft und Konfliktregeln statt einer eingefrorenen ersten Antwort.

Der Player hat eine eigene Frist

Ein Medienobjekt kann korrekt existieren und dennoch zu spät für eine Decoder-Abhängigkeit kommen. Eine Verbesserungsschicht kann bewusst nie erzeugt werden, während die Basisschicht funktioniert. Eintrittszeit, Puffer und Darstellung verändern das Nutzerergebnis.

MOQT definiert diese Anwendungsebene nicht. Betriebstelemetrie muss Objektbeobachtung, Statusquelle, Relay-Budget, Cache-Übergang, Codec-Abhängigkeit, Präsentationsfrist und sichtbares Ergebnis verknüpfen, aber getrennt halten. Erst dann lassen sich später Pfad, unvollständiger Cache, Publisher-Entscheidung und Player-Verwerfung unterscheiden.

Quellen