摘要

  • RFC 1301 规定，主节点看见 data[eom] 和中间所有数据包后，才把一条 MTP 消息标为接受；消息不完整时，则按其对发送者存活状态的判断保留为待定或改为拒绝。
  • 最近十二条消息的三态结果随每个后续报文传播；待定状态不能被移出末格，主节点必须暂停确认新发送令牌，先把旧的不确定性解决。
  • 这种机制在尽力而为的 IP 组播之上建立传输次序，却没有提供每个消费者的正向回执、应用语义、认证身份、永久审计或业务结果。

十二格是一段会移动的协议记忆

RFC 1301 的消息接受记录不是附属装饰。它包含同步标志、消息序号、分组序号，以及十二个各占两比特的位置。每个位置只有三种值：接受、待定、拒绝。新消息向前推进时，向量也向前滚动，第一格描述刚刚过去的消息，后面的格子依次回望更早的历史。

这十二格看上去像十二个接收者的表决，实际却完全不同。只有主节点有权设置状态。其他成员读取后续报文，从中学习主节点已经给早先消息作出的裁定。十二是时间窗口的长度，不是成员数量；三态是协议决策，不是十二份独立证词。

因此，“accepted”并不含糊。它在 MTP 内有严格含义。真正危险的是把这个词搬出自己的辖区，用它回答另一个问题：每个应用是否理解内容、是否被授权执行、是否改变了数据，以及用户最终得到了什么。

IP 组播只提供尽力而为的底座

RFC 1112 把 IP 组播定义为向一个动态主机组发送数据报。组成员可以加入和离开，发送者甚至不必属于该组。交付可靠性与普通 IP 单播一样，都是尽力而为：不保证数据报完整到达所有成员，也不保证相对顺序。

MTP 正是在这层不确定性之上加秩序。它把协作进程集合称为 web。其中必须有一个主节点，其余成员可以既生产又消费，也可以只消费。主节点建立 web、管理成员与运行参数，并分配发送令牌。生产者不能任意发出普通客户数据，必须先得到一个带消息序号的令牌。

网络层负责复制和转发，MTP 主节点负责谁先说、哪条消息被共同承认。应用仍然在更上方。三种控制面彼此相接，却不能互相冒名。

成功路径故意没有逐个确认

MTP 采用否定确认。消费者发现缺口时发送 NAK；没有发现缺口的消费者通常保持沉默，不向生产者逐一返回成功包。这样做能避免大型组播的反向确认风暴。

沉默不是毫无信息。它在协议的时序和保留假设内意味着没有观察到需要请求恢复的缺口。但沉默从来没有生成一张应用回执。它没有说明应用是否完成解析、是否把内容判为重复、是否允许执行，也没有证明外部状态改变。

后来的日志如果写成“全部消费者已确认”，就把节省掉的报文凭空造了回来。更诚实的记录应写明：主节点作出接受裁定，未观察到哪些 NAK，哪些成员在何时仍被视为在组内；至于应用结果，需要另一类证据。

主节点根据自己所见裁定完整性

接受规则非常具体。主节点必须看到某条消息的 data[eom]，还要看到此前所有中间分组，才把它标为接受。消息不完整、但发送者在主节点看来仍然运行并保持连接时，状态是待定。消息不完整、且发送者被认为故障或遭分区隔离时，状态变成拒绝。

这三态既包含观察，也包含判断。分组是否齐全是观察；生产者是否还活着则是主节点的判断。只保存最终向量，审计者看不到主节点收到了什么，也看不到它为何改变存活判断。必须把输入证据和裁定一起留住。

而且 MTP 把客户数据当作不解释的字节。主节点知道消息边界和序号，不知道字节是不是有效命令、过期对象或未经授权的请求。传输完整可以成立，应用拒绝也可以同时成立。

待定状态不能从窗口边缘掉下去

有限窗口迟早会遗忘旧状态。RFC 1301 没把十二格伪装成永久账本。但它禁止最不负责任的一种遗忘：尚未解决的待定不得越过最后一格。

如果最老的待定即将被推出，主节点必须停止确认新的令牌请求，直到把这条消息变成接受或拒绝。不确定性由此形成背压。系统不能通过继续分配序号，把尚未决定的过去从视野里推走。

这是一条很强的治理规则：先清偿证据债务，再允许新的工作扩大窗口。不过，已经终结的状态仍会随滚动而消失。需要长期追责的组织必须在窗口外建立耐久记录，保存裁定时间、依据和相关成员观察。

消息序号是十六位无符号数，由主节点初始化，并在每次授予令牌后递增。序号一经授予就被消耗，相关消息最终必须进入接受或拒绝。它限定一次传输实例里的秩序，不是永久业务对象 ID。

重复令牌确认暴露了证据歧义

控制报文不消耗普通序号，因此重复的令牌请求不一定能自证含义。可能是生产者没看到第一次确认；也可能生产者已经发了数据，只是主节点一个都没看到；还可能后发的重试在路上超过迟到的确认。

RFC 1301 不假装能从一个重试还原唯一过去。主节点若仍把令牌看作待定，可以重新分配。生产者收到重复确认时，把它当作 NAK，重发该消息序号下已经发过的数据。如果令牌已经不再需要，就用 empty[cancel] 归还。

这个动作让协议重新收敛，却没有证明究竟丢的是确认还是数据。监控系统应分别保存请求、确认、主节点观察、生产者发送和重传，而不是用最终成功倒推一条确定因果链。

heartbeat、window 与 retention 给恢复定价

三个共享参数约束运行。heartbeat 定义节奏；window 限制一个生产者在一个节拍里能够组播的新数据与重传分组总量；retention 规定数据和恢复状态至少保留多少个节拍。

客户暂时给不出完整分组、消息又尚未结束时，生产者发送 empty[dally] 保持同步。短消息还要补到至少与 retention 相同的分组数，提高消费者看见至少一个分组并识别生产者的概率。这是一种用重复换观察机会的措施，不是对所有成员完成交付的证明。

消费者可从序号跳跃发现丢失，也可从未结束片段后超过一个节拍的沉默发现问题。它以单播 NAK 列出缺失区间。生产者随后把请求的分组重新组播给整个 web，重传占用 window，并优先于新数据。未丢包的成员也会收到副本，因此必须抑制重复。

如果请求到来时数据已经超出 retention，生产者返回 nak[deny]。接收进程要把失败报告给客户，并可能退出 web。恢复窗口关闭之后，协议还能明确表示无法修复，却不能替应用补造一份从未存在的结果证明。

地址和成员资格也不是认证身份

MTP 在 IP 上要求 RFC 1112 的 Level 2 组播能力，使用永久组地址 224.0.1.9。由于 IP 本身没有进程端口，RFC 1301 还定义一个桥接头，在 IP 协议号 92 下携带源端口、目的端口、长度和可选校验和。

这些字段能定位传输实例，不能认证成员。RFC 1301 明说没有讨论安全。连接标识、TSAP、组成员状态和主节点角色都属于协议运行证据，若要证明人、设备或组织身份与授权，必须接入单独的安全来源。

后来的评估看见了集中控制的成本

RFC 1458 在评估大规模图像分发需求时回顾了 MTP。它承认令牌次序、流量控制、选择性 NAK 恢复和重复处理，也指出组地址与部分标识依赖外部机制，几乎所有控制流量集中到主节点会增加延迟与拥塞。对它研究的工作负载，MTP 并不合适。

这不是对某次传输成败的实证。它说明同一个控制结构既能提供共同次序，也会形成容量瓶颈。协议语义是否正确，与控制拓扑是否适合某个场景，是两种问题。

同一条消息在不同成员处留下不同证据

主节点看见完整消息时，可以依据规则宣布接受；某个消费者可能也完整收到，只是没有正向回应；另一个消费者可能先发现缺口、发出 NAK，再从全组重传中补齐；还有一个消费者可能等到数据已超出 retention，最终收到 nak[deny]。四种位置面对的是同一消息序号，却拥有不同的局部时间线。

共同状态的价值，是让成员在这些差异之上继续维持统一次序。它不是把差异从历史中抹掉。若档案只留下 accepted，NAK 来自谁、谁依靠重传恢复、谁的修复请求过晚、谁从未留下应用确认，全都会消失。反过来，若只保存一台消费者的抓包，也不能据此否定主节点按照自己完整观察作出的协议裁定。

因此，证据模型应允许“共同裁定一致、局部经历不同”同时成立。每个成员的接收与恢复记录需要自己的时间和身份；主节点的向量需要自己的决策来源；应用的处理结果还要有第三套回执。把三者强行合为一条成功记录，虽然让查询更简单，却会让任何异常都无法归责。

资料来源

这些材料证明历史协议规则和后来的设计评估，不证明真实 MTP 部署、接收者数量、认证成员、应用动作、事故、采用规模或当前结果。