CoAP 一条组播通知发给所有人，听众靠抽签数

Summary

2026 年 11 月 2 日的 CoAP 组播 Observe 草案第 17 版提出，关注同一资源的多个客户端可以接收服务器的一条组播通知。它仍是 IETF 工作中的草案。
Feedback-Divider 让每名愿意继续收听的客户端以 1 / 2^Q 的概率回复。服务器收到 R 份确认，计算反馈指标 E = R × 2^Q。
草案算例先估计有 32 名观察者，实际有 18 名仍活跃。五人抽中回话，一份回复丢失，服务器收到四份，推得指标 16，并在算例设定下把计数调为 16。

一批小型设备在盯着同一个状态值。按 RFC 7641 的 CoAP Observe 机制，每台设备都能登记订阅资源变化。服务器若逐台推送，发送量跟着人数上涨。新草案换了账本：让关注同一资源的客户端加入组，一次组播就通知所有收听者。发出一条消息很容易核对；知道多少设备真的还在收听，则需要另一套办法。

服务器会在本地构造一份“幽灵”Observe 请求，为组观察建立共同的 Token。并没有幽灵设备在网络上发包。客户端取得组参数后监听通知。服务器维持一个观察者计数，但草案称它只是活跃兴趣人数的粗估值。这个数字可以帮助服务器决定是否还值得维持组观察，不能替每个客户端签收某一次通知。

抽样回执不是签到簿

草案第八节给组播通知加上 Feedback-Divider，参数为 Q。支持该选项、也想继续收听的客户端各自从零到 2^Q 之前抽一个整数。只有抽中零的人等待随机短时间后，向服务器发起一次单播 Observe 重新登记。其他人继续收听而不回话。这样不会把一次组播变成所有客户端同时冲向服务器的回执风暴。

服务器只统计合格且实际到达的回话，记为 R，再乘 2^Q 得到指标 E。若邀请大约四分之一的人回答，收到四份便推估为 16。这个推估受随机波动影响，回执丢包还会把它拉偏。草案明说丢包会使估算失准。节省逐一通知的代价，是人数从逐个可见变成了统计推断。

计算过程中还有人加入。草案以当时的计数 COUNT' 为底，比较新的 E 与此前估计 N，再用正整数阻尼系数 D 调整：COUNT' + ((E − N) / D)。更新必须相对新登记操作保持原子性，避免旧一轮抽样覆盖刚加入的人。这条规则保护服务器内部状态，却仍不会生成逐设备的送达记录。

草案给了一个很好的算术警告。服务器原估计 32 人，选 Q=2，每人回话概率四分之一。真实活跃人数是 18；其中五人抽中，一份回复在路上丢失。服务器仅收到四份，算出 E=16；算例中 D=1，于是计数由 32 降到 16，组观察仍继续。现实中的服务器不会凭空知道“真实 18 人”；那是草案作者为展示误差而给读者的上帝视角。