摘要

  • RFC 3082 让用户代理订阅服务变化，而不是持续查询；是否部署 Directory Agent，决定通知机制采用哪种拓扑。
  • DA 消失后，已经收到通知指令的服务代理仍可继续发送；新服务代理却可能错过订阅。因此，旧通知没有中断，不代表新服务覆盖仍然完整。

查询不等于事件流

Service Location Protocol 的基础设计是按需发现：服务代理（SA）发布服务，用户代理（UA）需要时再查询。若应用想在服务出现或消失时立即更新本地视图，它就得周期性地重新询问网络。RFC 3082 于 2001 年 3 月以 Experimental 协议发布，目标是让这类应用通过通知获知变化，免去反复轮询。它并非 Internet Standard。

从“查询”改成“订阅后监听”看似简单，直到遇到一个新来的服务代理：谁来告诉它，已经有人在等待通知？RFC 3082 按网络中是否存在 Directory Agent（DA）分别作答。这两种设计并没有把相同状态放在同一个地方。

两种拓扑，两种代价

没有 DA 的小型网络中，SA 通过 IP 多播（若不可用则通过 IPv4 广播）发送注册和注销通知。UA 会收到比自身兴趣更广的消息，再按服务类型与 scope 过滤。这样无需一个中心代理逐一告知新 SA 有哪些订阅，却要求接收端处理无关通知，也让多播范围成为关键条件。

有 DA 的大型网络中，UA 在服务请求里附加 Subscribe 扩展。DA 返回与服务类型和 scope 对应的 NotifyAt 多播组地址，并可通过 DAAdvert 告知已有 SA。符合条件的新 SA 注册时，DA 还可以在 SrvAck 中带上 NotifyAt。若服务广告超时而没有正常注销，DA 也会发送注销通知。多数事件通知仍由 SA 发出；DA 并不是集中转发所有事件的中继站。

这种设计分散了工作，也分散了状态：DA 保存订阅，已获知订阅的 SA 保存组地址，UA 加入组播组，多播地址分配又有单独的范围和租期。为减少多个 DA 重复发送 NotifyAt，每个 DA 会随机等待 0 到 3 秒，并监听其他 DA 是否已发出匹配消息。这能压低重复通知，却不会复制订阅表，也不构成多个 DA 间的状态共识。

哪些信息会消失，哪些通知会继续

第 10 节对部分故障写得很清楚：DA 因意外情况消失时，它保存的 UA 订阅信息会丢失。但 UA 仍可收到既有 SA 的通知，因为这些 SA 早已获得 NotifyAt。新 SA 则不会知道该订阅，除非另一个 DA 也保存了相同信息。

UA 可能要等到主动发出请求，才发现替代 DA。于是，某项服务可能在旧 DA 消失后、UA 找到新 DA 并重新订阅前完成注册。通知流仍然有声有色，因为旧服务继续出现；新服务却可能从未进入这条流。

RFC 3082 为已经获知订阅的发送者提供了恢复路径：它们会通知到订阅过期；若暂时找不到其他 DA，则忽略过期时间，直到发现新 DA。SA 向新 DA 注册后，可从 SrvAck 得知 UA 是否续订。然而 RFC 也指出，重启后的 DA 已可用、UA 尚未重新订阅的这段间隙，仍可能有新 SA 启动而未获通知。若 UA 需要收到每一个新服务的通知，就应向每个新发现且支持相应 scope 的 DA 订阅。部署多个设备本身不会复制订阅状态。

收到通知，不等于服务交易完成

其他机制也要求把证据分层。多播通知会在 15 秒内以指数退避重复发送。RFC 说这会提高至少一个报文到达的概率，却没有承诺可靠送达或建立可重放的事件日志。属性列表可能超过 UDP 报文容量；溢出位会提醒 UA，若还需要更多属性，就应再向 SA 或 DA 查询。RFC 也规定了 UA 可校验的认证块，但认证成功不等于每个监听者都收到了消息、endpoint 仍可达，或应用请求已经完成。

因此需要分别记录：UA 订阅、DA 按类型与 scope 保存的状态、SA 收到的 NotifyAt、多播组监听、通知的发出与接收、属性不足时的后续查询，以及最终的服务交互。RFC 3082 规定了其中若干过渡机制，却没有把它们合并成一个端到端成功凭证。

标题两部分并不矛盾。RFC 3082 没有说一个 DA 故障会让所有通知停止：既有 SA 可以继续，其他 DA 也可能维持覆盖。它指出的是更窄、也更实用的边界：已知发送者继续活动，不等于后来加入的发送者也已纳入发现范围。以通知替代轮询，改变了系统必须记住“谁在听”的位置，也改变了恢复时必须补回的状态。

来源

协议与历史记录：RFC 3082、RFC Editor 记录、Datatracker 历史、RFC 2608：SLPv2、RFC 2119、RFC 2373、RFC 2730 与 RFC 2908。仅作编辑视角、不是 SLP 行为证据：Lu Heng 的 Running-Code Primacy 与 On Reality Layers。