Summary

  • 2026年11月2日付のCoAP Observe一斉通知草案・第17版は、同じ資源を監視する複数のクライアントへ一つの通知を送る仕組みを提案する。現時点では作業中のInternet-Draftだ。
  • 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を得る。四分の一の確率で返す設定なら、四件の到着は十六台を示唆する。十六台を一台ずつ確認したわけではない。抽選にはばらつきがあり、選ばれた端末の返事も途中で失われ得る。草案はパケット損失が推定を偏らせると記す。一通で済ませた分、人数の把握には統計上の幅が生じる。

抽選中に新しい端末が参加することもある。草案は現在のカウンターCOUNT'を基に、新指標Eと以前の推定Nとの差を正の整数Dで緩め、COUNT' + ((E − N) / D)とする。新規登録との関係で更新を原子的に行う必要がある。古い標本の補正によって、新たに入った端末を帳簿から消してはならない。ただし、帳簿が整っていても個々の通知の受信証明にはならない。

文書の例は誤差を目に見える形にする。もとの見込みは32台で、Q=2により返答確率は四分の一。実際に活動しているのは18台で、五台が返答を選ぶ。一件は失われ、サーバーには四件しか届かない。推定指標は16、例でD=1ならカウンターは32から16へ下がり、グループ監視は続く。「実際は18台」という情報は説明のために読者へ与えられた値だ。運用中のサーバーは到着した四件からしか推し量れない。

回線の節約を誰の判断に使うのか

Q=0なら活動中の全端末に返答を促せるが、返送トラフィックは増え、損失も残る。問い合わせ間隔を延ばせば負荷は軽くなる一方、カウンターは古くなる。Dを大きくすれば推定の動きは緩やかになる。いつ再確認し、何台以下でグループ監視をやめるかはアプリケーションが決める。早すぎる停止は待っている端末を取り残し、空のグループを維持すれば節約分が削られる。

RFC 7252がこの交換を支えるCoAPの基本を定める。草案が変えるのはObserve更新の配送コストだ。推定カウンターが示すのは継続して聞きたい人数であり、特定の端末が特定の通知を受け、処理し、行動した証拠ではない。環境の値を画面へ配る用途なら概数で経路を選べる。特定の装置へ操作を命じるなら、その装置から結果を受け取る仕組みが要る。

公式資料には実際の配備での損失分布や推定誤差の測定値がない。端末の実数を把握した試験で、抽選結果、失われた返答、通知の到着を同じ時系列に記録すれば、停止判断に使える誤差幅が分かる。一通で全員に知らせる節約は本物だ。その全員が何台かを知るには、くじを引くことになる。

CoAP一斉Observe草案 · Datatracker記録 · RFC 7641 · RFC 7252