摘要

  • RFC 3343 规定服务在处理 terminate 并发送回复后不再生成后续更新，同时明确提醒：此前发送的 presence 或 watcher 更新可能仍在途并于终止后抵达。
  • 代码 250 因而只证明服务侧活动操作已结束，不证明中继网已经排空；事务关联、订阅代际、内容时效和消费者处置必须分开。

许多系统把取消画成一条横线：线前属于任务，线后一切都应消失。RFC 3343 描述的却是分布式系统更真实的物理状态。源端能决定自己此后不再发什么，却不能瞬间收回已经交给传输层的消息。确认成功与迟到更新可以同时为真，因为它们记录的是链条上不同位置的事实。

真正的问题不是挑一份回执相信，而是避免让其中任何一份越过自己的证明范围。

三种长期操作

APEX 在线状态服务位于管理域内的知名端点 apex=presence。应用可以发布某个端点的状态条目，可以订阅该条目，也可以 watch 哪些端点正在订阅这个主体。

订阅会立即返回当前 presence 条目。持续时间非零时，条目变化会触发后续 publish，到期后服务发送 terminate；持续时间为零时，它只是一次性查询。watch 操作先返回 250，再为每个当前订阅者发出 notify，并在观察期限内继续报告订阅成功或终止。

这些并非一次请求一次响应的短事务。规范要求服务把 presence 条目和进行中的操作都保存在持久存储中。服务发出的 publish 与 notify 会携带触发它们的 subscribe 或 watch 事务标识符。标识符让来源可追踪，却不保证消息抵达时仍然有效。

250 回执到底结束了什么

消费者或服务都可终止订阅、观察。消费者提交对应事务标识符；若该标识符不属于这个发起者的进行中操作，服务返回错误 550。若匹配，服务删除活动操作并返回 250。

紧接着，RFC 写出关键限制：终止之后，发起者仍可能收到进一步的在线状态或观察者更新。服务在处理终止并发出回复后不会再发送新更新，但更早的更新可能仍在传输途中。

因此，250 证明的是服务持久状态已改变，并承诺未来停止生成或发送该操作的更新。它没有证明每个中继缓冲区、连接、调度器和消费者入口队列都为空，也没有撤回一条已经进入网格的消息。

若产品需要更强的“排空屏障”，就必须对边界之前的每条消息给出已交付、已丢弃或已核销的证明。RFC 3343 的终止回复没有冒充这种能力。

相关仍不等于当前有效

迟到更新保留了旧事务标识符，消费者可以准确判断它属于哪个已结束操作。相关性很有用，却不是执行命令。消费者还要维护订阅代际或终止墓碑，记录当前边界和晚到消息规则。

根据业务，旧更新可以被丢弃、留档、隔离，或与新的零时长快照比较。不能仅因标识符匹配就把内容应用到当前状态。“属于这次订阅”与“这次订阅仍有效”是两份证据。

同一发起者再次订阅同一主体时，RFC 会静默终止先前操作再继续。逻辑关系看似未变，代际却已经改变。如果账本没有代际，新订阅开始后到达的旧 publish 很容易被误认成新流的第一条数据。

Presence 条目不等于当前附着

每个管理域都要为所有端点维护 presence 条目，无论端点当前是否附着于中继网。条目包含 publisher、lastUpdate、发布者信息，以及至少一个带 destination、availableUntil 和能力描述的 tuple。

所以条目存在不证明端点在线，availableUntil 也不是一次真实交付的回执。终止后迟到的更新完全可能忠实复制服务曾存储的状态，同时对消费者的当下决策已经过时。

发布变更另有并发边界：提交的 lastUpdate 必须与存储值在语义上相同，否则返回 555。成功时服务更新条目、写入自己的当前时间并回复 250。这证明服务侧变更成功，不证明每个订阅者何时看见它。

历史记录与隐私边界

RFC 3343 于 2003 年 4 月以 Experimental 文档发表，目前为 Historic。IETF 在 2012 年 7 月 29 日的历史记录中写道，据其所知，RFC 3340 至 3343 没有已部署的实现，相应功能已由广泛部署的 XMPP 提供，依据为 RFC 6120 与 RFC 6121。

这段限定性记录没有说终止竞态导致未部署，也没有提供实现事故、排队时间或数据损坏案例。规范的安全部分另行提醒，presence 服务给出的时区偏移可能暴露位置；若敏感，可先转换时间，再用 -00:00 隐藏本地偏移信息。

这份历史文档留下的可靠方法很窄：分别保存更新生成、交给传输、终止受理、源端停止、传输排空、消费者收到和消费者执行。没有排空回执时，就不要虚构一份。取消已经成立，过去仍可能正在靠近。

来源