摘要

  • 当前 MOQT 草案明确：看到对象编号断档，只能证明观察到一个编号空洞，不能证明网络丢包或发布者从未生成该对象。
  • 协议分别表达永久不存在、状态未知和中继停止等待；监控、缓存与播放器也应保留这三种记录。

对象 418 到了，下一件是 420。仪表盘最自然的动作，是立刻给 419 记一次“丢失”。

draft-ietf-moq-transport-21 恰恰拒绝这种捷径。MOQT 面向实时媒体，但对象可能经由流或数据报传输，也可能经过中继、订阅、填充式 FETCH 与普通 FETCH。编号顺序不是完整的交付历史。419 可能尚未生成，可能不在当前订阅过滤范围内，可能仍在上游，也可能只是某个中继的等待预算耗尽；只有发布者或范围明确的权威信号，才能把“不知道”推进到“永远不会有”。

三种状态，不是一个“缺失”

9 月 8 日发布的第 21 版保留了第 20 版已经写明的三态模型。对于订阅者或缓存，一个对象可能已知存在、已知不存在，或者因为尚未收到或尚未生产而处于未知状态。第 21 版主要是结构整理，因此不能把这套三态语义包装成此次版本才出现的新发明。

真正重要的规则很窄：仅凭已观察到的 Object ID 空洞，不能推断被跳过的对象。不同子组可以走不同流；数据报和流的到达次序可以交错；中继缓存可能只握有两端；订阅过滤器也可能让某些对象从这条路径上消失。一个数字轴背后，是多条不同的保管链。

可靠的收据应先写清楚：哪个 Track、Group、Object、Subgroup，观察者是谁，经由订阅还是 FETCH，在什么时刻、什么路径上没有看到它。“在此截止时间前没有从这条路径出现”是事实；“从未存在”需要额外授权。

谁有资格说“永不存在”

Prior Object ID Gap 属性可以声明当前对象之前的一段编号不会、也永远不会存在。这个权限属于 Original Publisher，中继不能自行添加。若 FETCH 响应已经用等价方式表达同一空洞，中继可以移除重复属性，但不能改写其含义。Prior Group ID Gap 对整组执行相同的逻辑。

另一个强信号来自有边界、正常结束的 FETCH。即便如此，当前线格式也没有把所有未返回位置都解释为永久不存在，而是定义了三种范围终点：End of Non-Existent Range、End of Unknown Range 与 End of Timed-Out Range。

这三者对应不同控制面。发布者能对“是否创造”作持久声明；中继能报告自己的缓存与等待结果；订阅者能提出等待预算。任何一方都不应悄悄替另外两方说话。

超时只是预算收据

当前草案延续的一项关键新机制，是第 20 版加入的 End of Timed-Out Range。合并记录显示，设计者专门增加 0x20C，用于把 Fill Timeout 到期后放弃等待的对象，与真正未知的对象分开。

FILL_TIMEOUT 不是存在性预言器。它是一个请求为了上游 FETCH 总共愿意等待多少毫秒的预算。设为零，只要立即可用对象；没有参数，中继使用实现自定时长；订阅者要求的时间太长，中继还可以缩短而不通知。

因此，Timed-Out 的准确含义是：这个中继处理这个请求时，在这个预算下不再等待。它不证明网络丢了包，也不证明发布者从未生成对象，更不证明持续运行的订阅或另一台中继稍后不会把对象送来。

草案甚至允许更棘手的情况：某条路径曾记录对象不存在，另一条延迟路径后来又送到该对象，这不自动构成协议错误，也不自动使 Track 畸形。真实实现需要冲突调和规则，而不是把第一次观察永久写成真相。

播放器还有另一只钟

媒体应用拥有自己的截止时间。某个视频对象真实存在，也成功取回，却可能因为晚于解码依赖而变得无用。反过来，一个增强层对象从未生产，也可能不影响基础层播放。同一个对象，两位用户会因为加入时间、缓冲深度或所选表示不同而得到不同结果。

这些不是 MOQT 传输层替应用决定的语义。运维系统应连接但不要合并：对象观察、状态信号、中继预算、缓存变化、解码依赖、呈现截止时间和可见播放结果。只有保留这条链，团队才能分清路径故障、缓存不完整、发布者意图与播放器来不及使用有效数据。

来源