Résumé

  • Dans le projet MOQT actuel, un saut d’identifiant décrit une discontinuité observée ; il ne prouve ni perte réseau ni absence de production.
  • Le protocole sépare l’absence définitive, l’état encore inconnu et l’expiration du budget d’attente d’un relais. La télémétrie doit faire de même.

L’objet 418 arrive, puis l’objet 420. Un tableau de bord pressé inscrira presque mécaniquement « une perte » pour 419. Le projet draft-ietf-moq-transport-21 interdit pourtant cette conclusion.

MOQT distribue des médias par flux ou datagrammes, directement ou via des relais, avec des abonnements et des FETCH bornés. L’ordre des numéros ne raconte donc pas toute l’histoire de livraison. L’objet 419 peut ne pas avoir encore été produit, être exclu de ce chemin, attendre en amont, avoir dépassé le budget d’un relais ou faire l’objet d’une déclaration durable du producteur. Ces faits n’ont ni le même auteur ni la même portée.

L’inconnu n’est pas une absence

La révision 21, publiée le 8 septembre, conserve le modèle à trois états déjà présent dans la révision 20 : un objet est connu comme existant, connu comme inexistant, ou inconnu parce qu’il n’a pas encore été reçu ou produit. Cette nouvelle révision réorganise surtout le document ; elle n’a pas inventé ce modèle.

La règle opérationnelle est stricte : un trou entre deux Object ID ne dit rien, à lui seul, sur les numéros sautés. Plusieurs sous-groupes peuvent voyager sur des flux différents. Un datagramme peut dépasser un voisin transporté de façon fiable. Un cache de relais peut posséder les deux bords du trou tout en interrogeant encore l’amont. Un filtre d’abonnement peut aussi masquer volontairement une partie de la plage.

La première écriture honnête est donc limitée : piste, groupe, objet, sous-groupe, chemin, observateur et horodatage. « Non reçu ici avant cette échéance » est une observation. « N’existera jamais » demande une autorité supplémentaire.

Le droit de dire « jamais »

La propriété Prior Object ID Gap annonce qu’une plage antérieure n’existe pas et n’existera jamais. Seul l’Original Publisher peut l’ajouter ; un relais ne peut pas fabriquer cette affirmation. Il peut la retirer uniquement si un FETCH exprime déjà la même lacune. Prior Group ID Gap applique le principe aux groupes entiers.

Un FETCH terminé et borné peut aussi communiquer l’état d’une plage. Mais son format distingue trois fins : End of Non-Existent Range, End of Unknown Range et End of Timed-Out Range. Cette grammaire répartit correctement le pouvoir. Le producteur parle de création durable ; le relais parle de sa garde et de son attente ; l’abonné fixe un budget. Aucun ne devrait usurper la voix des autres.

Le délai expiré décrit une décision locale

La modification récente importante, conservée dans la version actuelle, est l’ajout dans la révision 20 d’une plage « Timed-Out ». Le code 0x20C permet d’isoler les objets que le relais a cessé d’attendre après expiration de FILL_TIMEOUT, au lieu de les classer comme inconnus ou définitivement absents.

Ce paramètre est un budget total en millisecondes pour les requêtes amont déclenchées par un FETCH. Zéro signifie : ne servir que ce qui est immédiatement disponible. Sans paramètre, le relais choisit une durée propre à son implémentation. Si l’abonné demande davantage que ce que le relais accepte, celui-ci peut raccourcir l’attente sans le signaler.

Une plage Timed-Out signifie donc seulement : ce relais a cessé d’attendre, pour cette requête et avec ce budget. Elle ne prouve pas une perte de paquet, une non-production, ni l’impossibilité d’une livraison ultérieure par un abonnement ou un autre relais.

Le projet admet même qu’un objet puisse arriver par un chemin retardé après avoir été enregistré comme inexistant depuis une autre source, sans rendre automatiquement la piste mal formée. Les caches devront réconcilier des reçus contradictoires ; ils ne pourront pas transformer la première observation en vérité éternelle.

L’horloge du lecteur reste distincte

Une application média impose sa propre échéance. Un objet peut exister et arriver correctement, mais trop tard pour une dépendance de décodage. À l’inverse, une couche d’amélioration peut ne jamais être créée sans interrompre la couche de base. Deux spectateurs peuvent connaître des résultats différents selon leur instant d’arrivée, leur tampon ou la représentation choisie.

MOQT ne décide pas ces sémantiques applicatives. Une exploitation rigoureuse relie sans confondre : observation de l’objet, source du statut, budget du relais, transition du cache, dépendance du codec, échéance de présentation et effet visible. C’est la seule manière de distinguer défaut de chemin, cache incomplet, intention du producteur et donnée valable mais trop tardive.

Sources