4. サーバー側の要件 (Server-Side Requirements)
4.1. 要求 (Request)
Observe オプションを 0 (登録) に設定した GET 要求は、サーバーに対して、ターゲットリソースの現在の表現を返すだけでなく、そのリソースのオブザーバーのリストにクライアントを追加することも要求します。成功すると、サーバーはリソースの現在の表現を返し、クライアントがオブザーバーのリストにある限り、(セクション 1.3 で説明されているように) この表現を更新し続けなければなりません (MUST)。
オブザーバーのリストのエントリは、クライアントエンドポイントと、要求でクライアントによって指定されたトークンによってキー設定されます。一致するエンドポイント/トークンペアを持つエントリがすでにリストに存在する場合 (たとえば、クライアントがリソースへの関心を強化したい場合に発生します)、サーバーは新しいエントリを追加してはならず (MUST NOT)、既存のエントリを置換または更新しなければなりません (MUST)。
リソースのオブザーバーのリストに新しいエントリを追加できない、または追加する意思がないサーバーは、登録要求を静かに無視して、通常どおり GET 要求を処理できます (MAY)。結果の応答には Observe オプションを含めてはなりません (MUST NOT)。その欠如は、リソースへの変更が通知されないこと、たとえば、代わりにリソースの状態をポーリングする必要があることをクライアントに通知します。
GET 要求の Observe オプションが 1 (登録解除) に設定されている場合、サーバーは一致するエンドポイント/トークンペアを持つ既存のエントリをオブザーバーのリストから削除し、通常どおり GET 要求を処理しなければなりません (MUST)。結果の応答には Observe オプションを含めてはなりません (MUST NOT)。
4.2. 通知 (Notifications)
クライアントは、GET 要求への返信としてサーバーによって送信される追加の応答によって、リソース状態の変更を通知されます。そのような各通知応答 (初期応答を含む) は、GET 要求でクライアントによって指定されたトークンをエコーしなければなりません (MUST)。オブザーバーのリストに複数のエントリがある場合、クライアントに通知される順序は定義されていません。サーバーは任意の方法を使用して順序を決定できます。
通知は、2.05 (Content) または 2.03 (Valid) 応答コードを持つべきです (SHOULD)。ただし、その時点で通常の GET 要求が非 2.xx 応答を返すような方法でリソースの状態が変更された場合 (たとえば、リソースが削除された場合)、サーバーは適切な応答コード (4.04 Not Found など) を持つ通知を送信してクライアントに通知すべきであり (SHOULD)、その後、リソースのオブザーバーのリストから関連するエントリを削除しなければなりません (MUST)。
2.xx 通知で指定された Content-Format は、GET 要求への初期応答で使用されたものと同じでなければなりません (MUST)。サーバーがこの形式で通知を送信し続けることができない場合、4.06 (Not Acceptable) 応答コードを持つ通知を送信すべきであり (SHOULD)、その後、リソースのオブザーバーのリストから関連するエントリを削除しなければなりません (MUST)。
2.xx 通知には、以下のセクション 4.4 で指定されているシーケンス番号を持つ Observe オプションを含めなければなりません (MUST)。非 2.xx 通知には Observe オプションを含めてはなりません (MUST NOT)。
4.3. キャッシュ (Caching)
通知は GET 要求への返信としてサーバーによって送信される単なる追加の応答であるため、RFC 7252 [RFC7252] のセクション 5.6 で定義されているようにキャッシュの対象となります。
4.3.1. 鮮度 (Freshness)
初期応答を返した後、サーバーは、クライアントによって観察されるリソースの状態を、実際のリソース状態と可能な限り同期させ続けなければなりません (MUST)。
時々同期がずれることは避けられないため、サーバーは各表現について、観察された状態と実際の状態が不一致であることが許容されるまでの経過時間を示さなければなりません (MUST)。この経過時間はアプリケーションに依存し、Max-Age オプションを使用して通知で指定されなければなりません (MUST)。
リソースが変更されず、クライアントが現在の表現を持っている場合、サーバーは通知を送信する必要はありません。ただし、クライアントが通知を受信しない場合、クライアントは観察された状態と実際の状態がまだ同期しているかどうかを判断できません。したがって、最新の通知の経過時間が示された Max-Age よりも大きくなると、クライアントはもはやリソース状態の使用可能な表現を持っていません。サーバーは、以前に示された Max-Age が期限切れになる直前に、変更されていない表現と新しい Max-Age を持つ新しい通知を送信することによって、それを防ぐことを望む場合があります (MAY)。
4.3.2. 検証 (Validation)
クライアントは、ETag オプションを使用して要求にエンティティタグのセットを含めることができます。観察されたリソースがその状態を変更し、オリジンサーバーが 2.05 (Content) 通知を送信しようとしているとき、その通知がクライアントによって指定されたエンティティタグのセット内のエンティティタグを持っている場合は常に、サーバーは代わりに適切な ETag オプションを持つ 2.03 (Valid) 応答を送信できます (MAY)。
4.4. 並べ替え (Reordering)
メッセージは並べ替えられる可能性があるため、クライアントは通知がより新しい通知よりも遅く到着したかどうかを判断する方法を必要とします。この目的のために、サーバーは、送信する各通知の Observe オプションの値を、厳密に増加するシーケンス番号の下位 24 ビットに設定しなければなりません (MUST)。シーケンス番号は任意の値で開始でき (MAY)、256 秒未満以内に 2^23 を超えて増加するほど速く増加してはなりません (MUST NOT)。
通知のために選択されたシーケンス番号は、同じリソースに対して同じトークンを持つ同じクライアントに送信された以前の通知のシーケンス番号よりも大きくなければなりません (MUST)。Observe オプションの値は、送信時に最新でなければなりません (MUST)。通知が再送信される場合、サーバーは再送信前にオプションの値をその時点で最新のシーケンス番号に更新しなければなりません (MUST)。
実装上の注意: 要件を満たす簡単な実装は、ローカルクロックからタイムスタンプを取得することです。その場合、シーケンス番号はティック単位のタイムスタンプであり、1 ティック = (256 秒)/(2^23) = 30.52 マイクロ秒です。クロックが現在の日時を反映している必要はありません。
別の有効な実装は、リソースごとに 24 ビットの符号なし整数変数を保存し、リソースが状態変更を受けるたびにこの変数をインクリメントすることです (すべての状態変更後の最初の 256 秒間にリソースが 2^23 回未満状態を変更する場合)。これにより、リソース状態が変更されなかった場合に再送信時に Observe オプションの値を更新する必要がなくなります。
設計上の注意: 24 ビットのオプション値と 256 秒の期間の選択は、理論的には毎秒最大 65536 の通知レートを可能にします。ただし、制約のあるノードはかなり不正確なクロックを持つことが多く、クライアント側とサーバー側の不正確さが相殺されたり、影響が増大したりする可能性があります。したがって、最大通知レートは毎秒 32768 通知に削減されます。これは依然として約 1 kHz という最高の既知の設計目標 (ほとんどの CoAP アプリケーションはそれより数桁下になります) をはるかに超えていますが、最大 -50/+100% の合計クロック不正確さを許容します。
4.5. 送信 (Transmission)
通知は、確認可能または確認不可能なメッセージで送信できます。使用されるメッセージタイプは通常アプリケーションに依存し、各通知についてサーバーによって個別に決定される場合があります。
たとえば、多少予測可能または定期的な方法で変更されるリソースの場合、通知は確認不可能なメッセージで送信できます。頻繁に変更されないリソースの場合、通知は確認可能なメッセージで送信できます。サーバーは、状態変更の頻度と個々の通知の重要性に応じて、これら 2 つのアプローチを組み合わせることができます。
サーバーは、たとえばリソースの状態が頻繁に変更されている場合など、すぐに別の通知を送信することを知っている場合、通知の送信をスキップすることを選択できます (MAY)。また、同じリソース状態に対して複数の通知を送信することを選択することもできます (MAY)。ただし、何よりも、リソースが新しい状態変更を受けない場合、サーバーはリソースのオブザーバーのリストにあるクライアントが最終的に最新の状態を観察することを保証しなければなりません (MUST)。
たとえば、状態変更がバーストで発生した場合、サーバーは一部の通知をスキップし、確認不可能なメッセージで通知を送信し、バーストが終了したときに確認可能なメッセージで最後の通知を繰り返すことによって、クライアントが最新の状態変更を観察することを確認できます。
確認可能な通知に対するクライアントの確認は、クライアントがさらなる通知の受信に関心があることを示します。クライアントがリセットメッセージで確認可能または確認不可能な通知を拒否した場合、または確認可能な通知を再送信する最後の試行がタイムアウトした場合、クライアントはもはや関心がないと見なされ、サーバーはオブザーバーのリストから関連するエントリを削除しなければなりません (MUST)。
実装上の注意: 確認不可能な通知を拒否するリセットメッセージを適切に処理するには、サーバーは送信する確認不可能な通知のメッセージ ID を記憶する必要があります。これは、リソースが制約されたサーバーにとっては困難な場合があります。ただし、リセットメッセージは信頼性なく送信されるため、クライアントはリセットメッセージがサーバーによって受信されない場合に備えなければなりません。したがって、サーバーは常に、確認不可能な通知を拒否するリセットメッセージが失われたふりをすることができます。
サーバーがこれを行う場合、そのクライアントへの後続の通知を確認可能なメッセージで送信することにより、キャンセルを加速できます。
主に確認不可能なメッセージで通知を送信するサーバーは、少なくとも 24 時間ごとに、確認不可能なメッセージの代わりに確認可能なメッセージで通知を送信しなければなりません (MUST)。これにより、いなくなった、またはもはや関心のないクライアントがオブザーバーのリストに無期限に残るのを防ぎます。
4.5.1. 輻輳制御 (Congestion Control)
CoAP の基本的な輻輳制御は、RFC 7252 [RFC7252] のセクション 4.2 の指数バックオフメカニズムと RFC 7252 [RFC7252] のセクション 4.7 の制限によって提供されます。ただし、CoAP は、単純な要求/応答の相互作用に対する輻輳制御の責任をクライアントのみに負わせています。レート制限要求送信は、応答の送信を暗黙的に制御します。単一の要求が潜在的に無限の数の通知をもたらす場合、追加の責任をサーバーに負わせる必要があります。
輻輳を引き起こさないために、サーバーは、特定のクライアントに送信する同時未処理通知/応答の数を NSTART (デフォルトで 1。RFC 7252 [RFC7252] のセクション 4.7 を参照) に厳密に制限しなければなりません (MUST)。未処理の通知/応答とは、確認がまだ受信されておらず、最後の再送信試行がまだタイムアウトしていない確認可能なメッセージ、または以下のレート制限ルールから生じる待機時間がまだ経過していない確認不可能なメッセージのいずれかです。
サーバーは、クライアントへのラウンドトリップ時間 (RTT) ごとに平均して 1 つを超える確認不可能な通知を送信すべきではありません (SHOULD NOT)。サーバーがクライアントの RTT 推定値を維持できない場合、3 秒ごとに 1 つを超える確認不可能な通知を送信すべきではなく (SHOULD NOT)、可能であればさらに積極的でないレートを使用すべきです (SHOULD) (RFC 5405 [RFC5405] のセクション 3.1.2 も参照)。
高度な CoAP 輻輳制御メカニズムにより、将来、さらなる輻輳制御の最適化と検討が期待されます。
4.5.2. 高度な送信 (Advanced Transmission)
オブザーバーのリストにあるクライアントへの同時未処理通知/応答の数が NSTART 以上である間に、観察されたリソースの状態が変化する場合があります。この場合、サーバーは新しいリソース状態をすぐにクライアントに通知できず、未処理の通知/応答が完了するのを最初に待たなければなりません。
サーバーがクライアントに送信し、変更されたリソースに関連する未処理の通知/応答が存在する場合、サーバーが古いリソース状態の表現をクライアントに取得するための作業を停止し、代わりに現在の表現をクライアントに送信し始めて、クライアントによって観察されるリソース状態がサーバーの実際の状態とより緊密に同期したままになるようにすることが望ましいです。
この目的のために、サーバーは、古い通知の送信を中止し (ただし、現在の送信試行が完了する前ではありません)、新しい通知の新しい送信を開始する (ただし、中止された送信の再送信タイマーとカウンターは保持される) ことによって、送信プロセスを最適化できます (MAY)。
より詳細には、サーバーは、観察に関連する未処理の送信を次のように置き換えることができます (MAY)。