Summary

  • 2026年11月2日更新のCoRE発行購読草案第22版は、長い切断や休眠のあるCoAP端末向けにブローカーを提案する。発行者はトピックデータへPUTし、購読者はObserveまたはGETで最新の表現を読む。まだIESGの評価段階にある草案だ。
  • 第3.3節が定義する取得対象は最新の表現だけである。古い表現の取得方法と保存数は将来の仕様に残される。
  • トピックの存在、発行の受理、購読の成立、通知の到着を一つの成功表示にまとめられない。購読応答にObserveオプションがなければ、成功コードがあっても購読は成立していない。

工場の温度センサーが高温を報告し、一時間後には正常値を送ったとする。その間、保守端末はオフラインだった。再接続して最新値を読むと正常と表示される。ブローカーの最新記録を知る用途には役立つ。切断中の異常を調べる用途には、別の記録が要る。この工場は説明のための仮定で、草案が実事故として報じたものではない。

IETFのCoRE草案では、ブローカーがトピックの集合、設定用のトピック資源、データ用の別資源を持つ。発行者はデータ資源のURIへPUTする。購読者はRFC 7641に基づき、Observe: 0を付けたGETで更新を待つ。単発のGETで最新値を読むこともできる。設定用URIとデータ用URIに同じ形は要求されず、クライアントはtopic-data属性から後者を知る。互いにずっと起きていられない端末を仲介する設計である。

空の資源と消えた資源は違う

トピックを作成すると、データ資源も作られる。ただし最初の発行までは中身がない。草案はそのGETに提案段階の2.06 No Contentを用いる。資源そのものがなければ通常は4.04 Not Found。値があれば最新の表現を返す。監視画面が三つを同じ「データなし」にしてしまうと、作成直後、削除後、単なる未発行の区別がつかない。

第3.3節はさらに明確だ。定義されるのは最新のデータの読み出しで、以前の表現を取り出す機能は将来の仕様例として挙げられている。ブローカーが高温と常温の二回のPUTを受理したとしても、この草案だけを根拠に高温値の履歴を購読者が後から取り出せるとは言えない。警報の発生と解除を検証したい運用者は、別の持続的なイベント記録を用意する必要がある。

購読が成立したかどうかにも独立した証拠がある。最新値がある場合、Observe: 0への2.05 ContentにObserveオプションが付いて購読を示す。まだ値がなければ2.06 No ContentとObserveで登録し、最初の値を後の通知で受ける。応答にObserveがない場合、コードが成功を示していても購読は失敗である。max-subscribersの上限に達したブローカーはこのオプションを付けない。コードだけを見るクライアントは、見張りに就けなかったのに監視中と表示する。

トピック自体の寿命もある。削除すれば設定資源とデータ資源がともに消え、既存の観察者には最後の4.04が送られる。任意の有効期限で自動削除もできる。欠測の原因を調べるなら、端末の切断、購読の拒否、未発行の資源、トピックの終了をそれぞれ確かめなければならない。

ブローカーの受理と現場の対応は別の時計

発行PUTの成功は通常2.04 Changedとなる。RFC 7252のCoAP応答として、ブローカーが更新を受け付けたことは示す。全購読者が通知を受け、保守アプリが警報を出し、担当者が動いたことまでは示さない。発行が速すぎれば草案は4.29 Too Many Requestsを認め、Max-Ageで再試行までの待ち時間を伝える。センサー側の送信記録だけでは、拒まれた値と受理された値を混同する。

草案はクライアントとブローカー間の通信を保護するよう求める。そのうえで発行内容には、購読者が発行元を確認できるエンドツーエンドの保護を勧める。ブローカーとの安全な接続は、温度値を出したセンサーの身元確認を自動的に済ませない。身元が確認できても、通知の到着とアプリの対応は次の事実だ。

このブローカーの役割は小さくない。眠る端末に最後に発行された値を届けられる。一方、草案は全イベントの保存も現場での損失率も示していない。運用判断を変える事実は、切断中に受理された発行、購読者への配送、最終的な処理を時刻順につないだ記録である。最新の正常値は今を示す。消えた一時間の無罪証明にはならない。

CoRE草案 · RFC 7641 · RFC 7252