要約

  • RFC 7641 の Observe は、制約された環境で資源の現在表現を効率よく更新する仕組みであり、すべての中間状態の配達を保証するものではない。
  • 24 ビットの順序比較、128 秒の時間条件、Max-Age は「何を現在と扱えるか」を定めるが、再生可能な履歴や永続キューを作らない。
  • プロキシを含む運用では、最後に受理した表現と鮮度根拠、更新経路、終了理由を残し、全遷移が必要なら別の履歴機構を選ぶ必要がある。

登録に成功したことはレスポンスで分かる

クライアントは Observe=0 と Token を含む GET を送る。サーバーが Observe 付きの 2.xx を返せば、端点と Token を鍵とする観測者エントリーが成立する。以後の通知は最初の GET に対する追加レスポンスである。登録できない、またはしたくないサーバーは Observe を付けず通常の GET として応答できる。クライアントはその不在から、通知を待たずポーリングへ切り替えるべきだと判断できる。

変化がない資源を何度も問い合わせないため、電池、帯域、サーバー処理を節約できる。キャッシュとプロキシを使えることも REST の性質を保つ利点である。ただし RFC は汎用の publish/subscribe 網を置き換える意図がないと明記する。

Observe は best effort と eventual consistency を採る。資源が変化を止めれば、登録されたクライアントは最終的に現在表現へ収束する。しかし混雑時や変化が回線能力を超える場合、サーバーは任意個数の中間状態を省略できる。現在表示には適しても、イベント監査には自動的に適さない。

24 ビットは小さいからこそ規則がある

通知はクライアントの Token を返し、Observe 値を持つ。サーバーは厳密に増加する系列の下位 24 ビットを使用する。クライアントは通常の整数比較ではなくシリアル番号算術で新旧を決める。ラップ後の小さい値を、ラップ前の大きい値より新しいと判定するためである。

さらに、前回の最新通知から 128 秒を超えて届いた通知は、シリアル差に依存せず新しいと扱える。長い無通信後に小さな番号空間が曖昧になるのを避ける規則だ。物理イベントの発生時刻を証明するものではなく、空白中の変化数も示さない。

サーバーには、256 秒未満で 24 ビット空間の半分を超えて進めない制約もある。これは比較可能性を守る。再起動後の系列復元、Token の喪失、プロキシの永続化を証明するのは実装試験であり、番号の存在だけではない。

Max-Age が切れると「未知」になる

Max-Age は、観測表現と実資源のずれをどこまで許容するかを示す。受信表現の年齢が上限を超えれば、クライアントはそれが現在状態を表すと仮定してはならない。再取得または再登録が必要になる。

期限切れは、変化、パケット損失、故障のいずれも証明しない。運用上の状態は「古い」または「未知」である。UI が自動で正常値、ゼロ、直前値の保持へ変換するなら、それは RFC の命令ではなく製品のリスク判断である。

Confirmable 通知の ACK も履歴を完成させない。ACK は当該 CoAP メッセージの到着を確認する。通知は要求の方式と独立して Confirmable または Non-confirmable にできる。途中状態がそもそも送られなかった可能性は残る。

観測の終了は遅れて見えることがある

クライアントは観測を忘れ、後で未知の Token を持つ Confirmable 通知を Reset で拒否できる。あるいは同じ Token と Observe=1 の GET で明示的に登録解除できる。どちらのパケットも失われ得るため、クライアント側の終了とサーバー側の削除は同時ではない。

サーバーは確認通知やタイムアウトで不要な観測者を回収する。迅速な終了が電池、プライバシー、容量に影響するなら、製品は解除結果と再試行を観測可能にしなければならない。

集約は証拠の境界でもある

中間装置は下流の複数登録を一つの上流観測に集約できる。各ホップは通知数、メッセージ型、Observe 値、ローカル表現に基づく Max-Age を独立に決める。起点の負荷は下がるが、下流の時系列はプロキシの判断を含む。

必要なのは非難ではなく識別である。最終表現が起点通知、キャッシュ検証、再取得、再登録のどれから来たかを記録すれば、正しい集約と隠れた空白を区別できる。