8. Multicast CoAP (マルチキャストCoAP)
CoAPは、IPマルチキャストグループへのリクエスト送信をサポートします。これは、ユニキャストCoAPへの一連の差分によって定義されます。CoAPグループ通信のより一般的な議論は [GROUPCOMM] で提供されています。
マルチキャストサービス発見を使用して他のエンドポイントによって発見可能なサービスを提供するCoAPエンドポイントは、適切なall-CoAP-nodesマルチキャストアドレス (Section 12.8) の1つ以上に参加し、デフォルトのCoAPポートでリッスンします。エンドポイントは、他のマルチキャストアドレス (all-nodes IPv6アドレスを含む) でマルチキャストリクエストを受信するか、IPv4でブロードキャスト経由で受信する場合があることに注意してください; したがって、エンドポイントはそのようなメッセージを受信する準備をしなければなりませんが、マルチキャストサービス発見が望まれない場合は無視してもかまいません。
8.1. Messaging Layer (メッセージ層)
マルチキャストリクエストは、CoAPエンドポイントの代わりにIPマルチキャストアドレスにアドレス指定されたCoAPメッセージで転送されることによって特徴付けられます。そのようなマルチキャストリクエストは、Non-confirmableでなければなりません。
サーバーは、利用可能な場合、IPV6_RECVPKTINFO [RFC3542] などの最新のAPIを使用するなどして、リクエストがマルチキャスト経由で到着したことを認識すべきです。
エラー応答の爆発を回避するために、サーバーがリクエストがマルチキャスト経由で到着したことを認識している場合、Non-confirmableメッセージへの応答としてResetメッセージを返してはなりません。認識していない場合は、通常どおりNon-confirmableメッセージへの応答としてResetメッセージを返してもかまいません。そのようなResetメッセージは、送信者にとってユニキャストメッセージに対して送信されたものと同じに見えるため、送信者は、マルチキャストメッセージを受信する可能性のあるエンドポイントとこのエンドポイントからまだアクティブなメッセージIDの使用を避けなければなりません。
執筆時点では、マルチキャストメッセージはUDPでのみ伝送でき、DTLSでは伝送できません。これは、このドキュメントでCoAPに対して定義されているセキュリティモードがマルチキャストには適用されないことを意味します。
8.2. Request/Response Layer (リクエスト/レスポンス層)
サーバーがリクエストがマルチキャスト経由で到着したことを認識している場合、サーバーは、特に有用な応答がない場合 (例えば、空のペイロードまたはエラー応答しかない場合)、リクエストを常に無視してもかまいません。この決定はアプリケーションに依存する場合があります。(例えば、[RFC6690] で説明されているクエリフィルタリングでは、フィルタが一致しない場合、サーバーはマルチキャストリクエストに応答しません。[GROUPCOMM] にはより多くの例があります。)
サーバーがマルチキャストリクエストに応答することを決定した場合、すぐに応答すべきではありません。代わりに、応答する予定の期間の持続時間を選択すべきです。この説明の目的のために、この期間の長さをLeisureと呼びます。このLeisureの特定の値は、アプリケーションに依存する場合があるか、以下に説明するように導出されてもかまいません。その後、サーバーは、選択されたleisure期間内でランダムな時点を選択して、マルチキャストリクエストへのユニキャスト応答を送信すべきです。同じマルチキャストアドレスメンバーシップに基づいてさらなる応答を送信する必要がある場合、新しいleisure期間は前のものが終了した後最も早く開始されます。
Leisureの値を計算するために、サーバーはグループサイズ推定値G、目標データ転送速度R (両方とも保守的に選択)、および推定応答サイズSを持つべきです; Leisureの粗い下限は次のように計算できます
lb_Leisure = S * G / R
例えば、2.4 GHz IEEE 802.15.4 (6LoWPAN) ネットワーク上のリンクローカルスコープを持つマルチキャストリクエストの場合、Gは (比較的保守的に) 100に設定され、Sは100バイトに設定され、目標速度は8 kbit/s = 1 kB/sに設定できます。結果として得られるLeisureの下限は10秒です。
CoAPエンドポイントがLeisureの値を計算するための適切なデータを持っていない場合、DEFAULT_LEISUREを使用してもかまいません。
応答をマルチキャストリクエストと一致させる場合、tokenのみが一致しなければなりません; 応答のソースエンドポイントは、元のリクエストの宛先エンドポイントと同じである必要はありません (また同じにはなりません)。
Location-*オプションと表現に埋め込まれたリンクを解釈する目的で、リクエストURI (つまり、応答が解釈される相対的なベースURI) は、元のリクエストURIのHostコンポーネント内のマルチキャストアドレスを、実際に応答しているエンドポイントのリテラルIPアドレスで置き換えることによって形成されます。
8.2.1. Caching (キャッシング)
クライアントがマルチキャストリクエストを行う場合、常にマルチキャストグループへの新しいリクエストを行います (その間に参加した、または以前のリクエストを受け取らなかった新しいグループメンバーがいる可能性があるため)。受信した応答でキャッシュを更新してもかまいません。その後、キャッシュされた-まだ新鮮な応答と新しい応答の両方をリクエストの結果として使用します。
マルチキャストグループへのGETリクエストへの応答として受信された応答は、関連するユニキャストリクエストURIでの後続のリクエストを満たすために使用されてもかまいません。ユニキャストリクエストURIは、リクエストURIの権限部分を応答メッセージのトランスポート層ソースアドレスで置き換えることによって取得されます。
キャッシュは、関連するユニキャストリクエストURIでGETリクエストを行うことによって応答を再検証してもかまいません。
マルチキャストグループへのGETリクエストには、ETagオプションを含めてはなりません。クライアントがすでに持っている応答を抑制するメカニズムは、今後の研究に委ねられます。
8.2.2. Proxying (プロキシング)
フォワードプロキシがマルチキャストアドレスを示すProxy-UriまたはProxy-Schemeから構築されたURIを持つリクエストを受信した場合、プロキシは上記のように一連の応答を取得し、すべての応答 (キャッシュされた-まだ新鮮なものと新しいもの) を元のクライアントに送信します。
この仕様は、このように転送された応答でユニキャスト変更されたリクエストURI (ベースURI) を示す方法を提供しません。マルチキャストリクエストのプロキシングは [GROUPCOMM] でより詳細に議論されています; ベースURIの問題に対処する1つの方法は [CoAP-MISC] のSection 3で見つけることができます。