4. Message Transmission (メッセージ伝送)
CoAPメッセージはCoAPエンドポイント間で非同期に交換されます. これらはCoAP要求と応答の転送に使用され, そのセマンティクスはセクション5で定義されています.
CoAPはUDPのような信頼性のないトランスポートに結合されているため, CoAPメッセージは順不同で到着したり, 重複して表示されたり, 通知なしに失われたりする可能性があります. このため, CoAPはTCPのようなトランスポートの完全な機能セットを再作成しようとせずに, 軽量の信頼性メカニズムを実装します. これには次の機能があります:
-
確認可能メッセージ (Confirmable messages) 用の指数バックオフを伴うシンプルなストップアンドウェイト再送信信頼性.
-
確認可能メッセージと非確認可能メッセージ (Non-confirmable messages) の両方の重複検出.
4.1. Messages and Endpoints (メッセージとエンドポイント)
CoAPエンドポイントはCoAPメッセージの送信元または宛先です. エンドポイントの具体的な定義は, CoAPに使用されているトランスポートに依存します. この仕様で定義されているトランスポートの場合, エンドポイントは使用されているセキュリティモードに応じて識別されます (セクション9を参照): セキュリティがない場合, エンドポイントはIPアドレスとUDPポート番号のみで識別されます. 他のセキュリティモードでは, エンドポイントはセキュリティモードで定義されたとおりに識別されます.
メッセージには異なるタイプがあります. メッセージのタイプは, CoAPヘッダーのTypeフィールドで指定されます.
メッセージタイプとは別に, メッセージは要求, 応答を運ぶか, または空 (Empty) である可能性があります. これはCoAPヘッダーのRequest/Response Codeフィールドによって通知され, 要求/応答モデルに関連しています. このフィールドの可能な値はCoAP Code Registries (セクション12.1) で維持されています.
空メッセージはCodeフィールドが0.00に設定されています. Token Lengthフィールドは0に設定しなければならず (MUST), Message IDフィールドの後にデータのバイトが存在してはなりません (MUST NOT). バイトが存在する場合, それらはメッセージフォーマットエラーとして処理しなければなりません (MUST).
4.2. Messages Transmitted Reliably (信頼性のある伝送メッセージ)
メッセージの信頼性のある伝送は, CoAPヘッダーでメッセージをConfirmableとしてマークすることによって開始されます. Confirmableメッセージは常に要求または応答のいずれかを運びますが, Resetメッセージを引き出すためだけに使用される場合は空です. 受信者は (a) AcknowledgementメッセージでConfirmableメッセージを確認するか (MUST), または (b) 受信者がメッセージを適切に処理するコンテキストを欠いている場合 (メッセージが空である, 予約されたクラス (1, 6, または7) のコードを使用している, またはメッセージフォーマットエラーがある状況を含む) はメッセージを拒否しなければなりません (MUST). Confirmableメッセージの拒否は, 一致するResetメッセージを送信し, それ以外は無視することによって実行されます. Acknowledgementメッセージは, ConfirmableメッセージのMessage IDをエコーしなければならず (MUST), 応答を運ぶか空でなければなりません (MUST) (セクション5.2.1および5.2.2を参照). ResetメッセージはConfirmableメッセージのMessage IDをエコーしなければならず (MUST), 空でなければなりません (MUST). AcknowledgementまたはResetメッセージの拒否 (Acknowledgementが要求または予約されたクラスのコードを運ぶ場合, またはResetメッセージが空でない場合を含む) は, それを黙って無視することによって実行されます. より一般的には, AcknowledgementおよびResetメッセージの受信者は, AcknowledgementまたはResetメッセージで応答してはなりません (MUST NOT).
送信者は, 確認応答 (またはResetメッセージ) を受信するか試行回数がなくなるまで, 指数関数的に増加する間隔でConfirmableメッセージを再送信します.
再送信は, CoAPエンドポイントが確認応答 (またはreset) を待っている間に送信する各Confirmableメッセージについて追跡しなければならない (MUST) 2つのもので制御されます: タイムアウトと再送信カウンター. 新しいConfirmableメッセージの場合, 初期タイムアウトはACK_TIMEOUTと (ACK_TIMEOUT * ACK_RANDOM_FACTOR) の間のランダムな期間 (多くの場合整数秒ではない) に設定され (セクション4.8を参照), 再送信カウンターは0に設定されます. タイムアウトがトリガーされ, 再送信カウンターがMAX_RETRANSMIT未満の場合, メッセージが再送信され, 再送信カウンターがインクリメントされ, タイムアウトが2倍になります. 再送信カウンターがタイムアウト時にMAX_RETRANSMITに達するか, エンドポイントがResetメッセージを受信した場合, メッセージを送信する試みはキャンセルされ, アプリケーションプロセスに失敗が通知されます. 一方, エンドポイントが時間内に確認応答を受信した場合, 送信は成功したと見なされます.
この仕様は, 上記のバイナリ指数バックオフアルゴリズムを実装するために使用されるクロックの精度について強い要件を設けていません. 特に, エンドポイントはそのスリープスケジュールのために特定の再送信に遅れる可能性があり, 次の再送信で追いつく可能性があります. ただし, 別の再送信の前の最小間隔はACK_TIMEOUTであり, (再) 送信のシーケンス全体はMAX_TRANSMIT_SPANのエンベロープ内に留まらなければなりません (MUST) (セクション4.8.2を参照), たとえそれが送信者が送信の機会を逃す可能性があることを意味するとしてもです.
Confirmableメッセージを送信したCoAPエンドポイントは, MAX_RETRANSMITカウンター値に達する前でも, ACKを取得する試みを諦めることができます (MAY). たとえば, アプリケーションが応答を必要としなくなったために要求をキャンセルした場合, またはCONメッセージが実際に到着したという他の兆候がある場合です. 特に, CoAP要求メッセージが分離応答を引き出した可能性があり, その場合, 要求者にはACKのみが失われたことが明らかであり, 要求の再送信は無意味です. ただし, レスポンダーは今度は要求者からのこのクロスレイヤー動作に依存してはならず (MUST NOT), つまり, Confirmable応答が既に要求者によって確認されている場合でも, 必要に応じて要求のACKを作成するための状態を保持しなければなりません (MUST).
再送信を諦めるもう1つの理由は, ICMPエラーの受信である可能性があります (MAY). ICMPエラーを考慮することが望まれる場合, 潜在的なスプーフィング攻撃を軽減するために, 実装はICMPメッセージ内の元のデータグラムに関する情報 (ポート番号やメッセージタイプとコード, Message ID, Tokenなどの CoAPヘッダー情報を含む) をチェックするように注意すべきです (SHOULD); UDPサービスAPIの制限のためにこれが不可能な場合, ICMPエラーは無視すべきです (SHOULD). Packet Too Bigエラー [RFC4443] (IPv4の "fragmentation needed and DF set" [RFC0792]) は適切に発生することができず, セクション4.6の実装ノートに従う場合は無視すべきです (SHOULD); そうでない場合, それらはパスMTU発見アルゴリズム [RFC4821] にフィードすべきです (SHOULD). Source QuenchおよびTime Exceeded ICMPメッセージは無視すべきです (SHOULD). ホスト, ネットワーク, ポート, またはプロトコルの到達不能エラーまたはパラメータ問題エラーは, 適切な審査の後, 送信の失敗をアプリケーションに通知するために使用される可能性があります (MAY).
4.3. Messages Transmitted without Reliability (信頼性のない伝送メッセージ)
一部のメッセージは確認応答を必要としません. これは, アプリケーション要件のために定期的に繰り返されるメッセージ (最終的な成功で十分であるセンサーからの繰り返し読み取りなど) に特に当てはまります.
より軽量な代替手段として, メッセージをNon-confirmableとしてマークすることで, メッセージをより低い信頼性で送信できます. Non-confirmableメッセージは常に要求または応答のいずれかを運び, 空であってはなりません (MUST NOT). Non-confirmableメッセージは受信者によって確認されてはなりません (MUST NOT). 受信者がメッセージを適切に処理するコンテキストを欠いている場合 (メッセージが空である, 予約されたクラス (1, 6, または7) のコードを使用している, またはメッセージフォーマットエラーがある場合を含む), 受信者はメッセージを拒否しなければなりません (MUST). Non-confirmableメッセージの拒否には, 一致するResetメッセージの送信が含まれる可能性があり (MAY), Resetメッセージとは別に, 拒否されたメッセージは黙って無視しなければなりません (MUST).
CoAPレベルでは, 送信者がNon-confirmableメッセージが受信されたかどうかを検出する方法はありません. 送信者はMAX_TRANSMIT_SPAN内でNon-confirmableメッセージの複数のコピーを送信することを選択できます (MAY) (セクション4.7の規定によって制限され, 特に応答が受信されない場合はPROBING_RATEによって制限されます), またはネットワークが転送中にメッセージを複製する可能性があります. 受信者がメッセージに対して一度だけ動作できるようにするために, Non-confirmableメッセージもMessage IDを指定します. (このMessage IDは, ConfirmableメッセージのMessage IDと同じ番号空間から引き出されます.)
セクション4.2と4.3をまとめると, 4つのメッセージタイプは表1のように使用できます. "*"は, この組み合わせが通常の操作では使用されず, Resetメッセージを引き出すためにのみ使用されることを意味します ("CoAP ping").
+----------+-----+-----+-----+-----+
| | CON | NON | ACK | RST |
+----------+-----+-----+-----+-----+
| Request | X | X | - | - |
| Response | X | X | X | - |
| Empty | * | - | X | X |
+----------+-----+-----+-----+-----+
表 1: メッセージタイプの使用法
4.4. Message Correlation (メッセージ相関)
AcknowledgementまたはResetメッセージは, 対応するエンドポイントの追加アドレス情報とともにMessage IDによってConfirmableまたはNon-confirmableメッセージと相関されます. Message IDは, ConfirmableまたはNon-confirmableメッセージの送信者によって生成され, CoAPヘッダーに含まれる16ビットの符号なし整数です. 受信者はAcknowledgementまたはResetメッセージでMessage IDをエコーしなければなりません (MUST).
同じMessage IDはEXCHANGE_LIFETIME内で (同じエンドポイントとの通信時に) 再利用してはなりません (MUST NOT) (セクション4.8.2).
実装ノート: Message IDを生成するためにいくつかの実装戦略を採用できます. 最も単純なケースでは, CoAPエンドポイントは単一のMessage ID変数を保持することによってMessage IDを生成し, 宛先アドレスまたはポートに関係なく, 新しいConfirmableまたはNon-confirmableメッセージが送信されるたびにその変数を変更します. 多数のトランザクションを処理する必要があるエンドポイントは, たとえばプレフィックスまたは宛先アドレスごとに複数のMessage ID変数を保持できます. (一部の受信エンドポイントは, それに宛てられたユニキャストパケットとマルチキャストパケットを区別できない可能性があるため, Message IDを生成するエンドポイントはこれらが重複しないようにする必要があることに注意してください.) 変数の初期値 (たとえば起動時) をランダム化することを強くお勧めします (RECOMMENDED). これにより, プロトコルに対するパス外攻撃が成功する可能性が低くなります.
AcknowledgementまたはResetメッセージをConfirmableまたはNon-confirmableメッセージと一致させるには, AcknowledgementまたはResetメッセージのMessage IDとソースエンドポイントが, ConfirmableまたはNon-confirmableメッセージのMessage IDと宛先エンドポイントと一致しなければなりません (MUST).
4.5. Message Deduplication (メッセージ重複排除)
受信者は, EXCHANGE_LIFETIME (セクション4.8.2) 内で同じConfirmableメッセージ (Message IDとソースエンドポイントで示される) を複数回受信する可能性があります. たとえば, その確認応答が失われたか, 最初のタイムアウト前に元の送信者に到達しなかった場合です. 受信者は同じAcknowledgementまたはResetメッセージを使用してConfirmableメッセージの各重複コピーを確認すべきですが (SHOULD), メッセージ内の要求または応答は一度だけ処理すべきです (SHOULD). Confirmableメッセージで送信される要求が冪等である (セクション5.1を参照) か, 冪等な方法で処理できる場合, このルールは緩和できます. 緩和されたメッセージ重複排除の例:
-
サーバーは, Message IDの状態を維持する必要がないように, 同じ応答で冪等要求のすべての再送信に応答する要件を緩和する場合があります (MAY) (セクション4.2). たとえば, 重複処理によって生じる作業量が以前の応答を追跡するのに必要な作業量よりも安価である場合, 実装はGET, PUT, またはDELETE要求の重複送信を別々の要求として処理したい場合があります.
-
制約のあるサーバーは, アプリケーションセマンティクスがこのトレードオフを有利にする場合, 特定の非冪等要求に対してもこの要件を緩和したい場合があります (MAY). たとえば, POST要求の結果がサーバーで短期間の状態を作成するだけである場合, 同じ要求の以前の送信が既に処理されたかどうかを追跡するよりも, 要求に対してこの作業を複数回発生させる方が安価である可能性があります.
受信者は, NON_LIFETIME (セクション4.8.2) 内で同じNon-confirmableメッセージ (Message IDとソースエンドポイントで示される) を複数回受信する可能性があります. 一般的なルールとして (メッセージの特定のセマンティクスに基づいて緩和できます), 受信者は重複したNon-confirmableメッセージを黙って無視すべきであり (SHOULD), メッセージ内の要求または応答は一度だけ処理すべきです (SHOULD).
4.6. Message Size (メッセージサイズ)
メッセージが単一のIPパケット内に収まること (IP断片化を回避すること) が望ましいですが, これは実装品質の問題です. CoAP仕様自体はメッセージサイズの上限のみを提供します. IPパケットより大きいメッセージは望ましくないパケット断片化を引き起こします. CoAPメッセージは, 適切にカプセル化されて, 単一のIPパケット内に収まるべきであり (SHOULD) (つまりIP断片化を回避する), (1つのUDPペイロードに収まることで) 明らかに単一のIPデータグラム内に収まる必要があります. Path MTUが不明な場合, IP MTUは1280バイトと仮定すべきです (SHOULD); ヘッダーのサイズについて何もわからない場合, メッセージサイズの適切な上限は1152バイト, ペイロードサイズは1024バイトです.
実装ノート: CoAPのメッセージサイズパラメータの選択は, IPv6および今日のほとんどのIPv4パスでうまく機能します. (ただし, IPv4では, IP断片化がないことを絶対に保証することは困難です. 異常なネットワークでのIPv4のサポートが重要な考慮事項である場合, 実装は576バイトなどのより保守的なIPv4データグラムサイズに自分自身を制限したい場合があります; [RFC0791]によると, IPv4のIP MTUの絶対最小値は68バイトと低く, UDPペイロードにはセキュリティオーバーヘッドを差し引いた40バイトしか残りません. この問題セットに極端に焦点を当てた実装は, IPv4 DFビットを設定し, 何らかの形式のパスMTU発見 [RFC4821]を実行したい場合もあります; ただし, これはCoAPの現実的な使用例では通常不要です.) 多くの制約されたネットワークでより重要なのは, アダプテーションレイヤーでの断片化です (たとえば, 6LoWPAN L2パケットはさまざまなオーバーヘッドを含めて127バイトに制限されています); これにより, 実装がパケットサイズで節約し, メッセージサイズが3桁の範囲に近づくときにブロック単位転送 [BLOCK]に移行することが促進される可能性があります.
メッセージサイズは, 制約されたノード上の実装者にとっても非常に重要です. 多くの実装は, 受信メッセージ用のバッファを割り当てる必要があります. 実装が上記の上限の割り当てを許可するには制約されすぎている場合, DTLSセキュリティを使用しないメッセージに対して次の実装戦略を適用できます: 小さすぎるバッファにデータグラムを受信する実装は, 通常, データグラムの末尾が破棄されたかどうかを判断し, 初期部分を取得できます. したがって, 少なくともCoAPヘッダーとオプション (ペイロード全体でない場合) はバッファ内に収まる可能性があります. したがって, ペイロードが切り捨てられた場合, サーバーは要求を完全に解釈し, 4.13 (Request Entity Too Large; セクション5.9.2.9を参照) 応答コードを返すことができます. 冪等要求を送信し, バッファに収まるよりも大きい応答を受信するクライアントは, Blockオプション [BLOCK]の適切な値で要求を繰り返すことができます.
4.7. Congestion Control (輻輳制御)
CoAPの基本的な輻輳制御は, セクション4.2の指数バックオフメカニズムによって提供されます.
輻輳を引き起こさないために, クライアント (プロキシを含む) は, 特定のサーバー (プロキシを含む) に対して維持する同時未処理相互作用の数をNSTARTに厳密に制限しなければなりません (MUST). 未処理相互作用とは, ACKがまだ受信されておらずまだ待機中のCON (メッセージレイヤー), または応答も確認応答メッセージもまだ受信されておらずまだ待機中の要求 (Message IDとトークンで照合可能) のいずれかです (両方が同時に発生する可能性があり, 1つの未処理相互作用としてカウントされます). この仕様におけるNSTARTのデフォルト値は1です.
セクション4.8で定義されたCoAP伝送パラメータの自動初期化の可能性など, さらなる輻輳制御の最適化と考慮事項が将来期待されており, これによりNSTARTの値が1より大きくなる可能性もあります.
EXCHANGE_LIFETIMEの後, クライアントは確認応答メッセージが受信されなかったConfirmable要求に対する応答を期待するのを停止します. 確認された要求またはNon-confirmable要求に対する応答を "期待する" のを停止する特定のアルゴリズムは定義されていません. 追加の輻輳制御最適化によって変更されない限り, 応答しない別のエンドポイントへの送信時にエンドポイントがPROBING_RATEの平均データレートを超えないように選択しなければなりません (MUST).
注: CoAPは輻輳制御の責任を主にクライアントに課します. ただし, クライアントは誤動作している可能性があり, または実際に攻撃者である可能性があります. たとえば, 増幅攻撃を実行する場合 (セクション11.3) です. 損害 (ネットワークおよび自身のエネルギーリソースへの) を制限するために, サーバーはアプリケーション要件に関する合理的な仮定に基づいて, その応答送信に対して何らかのレート制限を実装すべきです (SHOULD). このために, サーバーは異なるサービスとリソースに対して個別のレートリミッターを使用できます (MAY).
4.8. Transmission Parameters (伝送パラメータ)
メッセージ伝送は次のパラメータによって制御されます:
+-------------------+---------------+
| name | default value |
+-------------------+---------------+
| ACK_TIMEOUT | 2 seconds |
| ACK_RANDOM_FACTOR | 1.5 |
| MAX_RETRANSMIT | 4 |
| NSTART | 1 |
| DEFAULT_LEISURE | 5 seconds |
| PROBING_RATE | 1 byte/second |
+-------------------+---------------+
表 2: CoAPプロトコルパラメータ
4.8.1. Changing the Parameters (パラメータの変更)
ACK_TIMEOUT, ACK_RANDOM_FACTOR, MAX_RETRANSMIT, NSTART, DEFAULT_LEISURE (セクション8.2), およびPROBING_RATEの値は, アプリケーション環境に固有の値 (動的に調整された値を含む) に設定できます (MAY); ただし, 設定方法はこのドキュメントの範囲外です. アプリケーション環境はこれらのパラメータに一貫した値を使用することが推奨されます (RECOMMENDED); アプリケーション環境で互換性のない値で動作する具体的な影響は, この仕様の範囲外です.
伝送パラメータは, インターネット上で使用しても安全な動作を実現するように選択されています. 設定が異なる値を使用したい場合, これらの輻輳制御特性が違反されていないことを保証する責任は設定にあります. 特に, ACK_TIMEOUTを1秒未満に減らすことは[RFC5405]のガイダンスに違反します. ([RTO-CONSIDER]は追加の背景を提供します.) CoAPは, ラウンドトリップタイム (RTT) 測定を維持しない実装を可能にするように設計されています. ただし, ACK_TIMEOUTを大幅に減らすかNSTARTを増やすことが望まれる場合, これはそのような測定を維持する場合にのみ安全に実行できます. 設定は, 輻輳制御の安全性を保証するメカニズムを使用せずにACK_TIMEOUTを減らしたりNSTARTを増やしたりしてはならず (MUST NOT), これらのメカニズムは設定で定義されるか, 将来の標準文書で定義されます.
ACK_RANDOM_FACTORは1.0未満に減らしてはならず (MUST NOT), 同期効果からある程度の保護を提供するために1.0と十分に異なる値を持つべきです (SHOULD).
MAX_RETRANSMITは自由に調整できますが, 値が小さすぎるとConfirmableメッセージが実際に受信される確率が低下し, ここで示された値よりも大きい値は時間値のさらなる調整を必要とします (セクション4.8.2を参照).
伝送パラメータの選択が派生時間値の増加をもたらす場合 (セクション4.8.2を参照), 設定メカニズムは, 調整された値がこれらの調整された値を使用して通信するすべてのエンドポイントでも利用可能であることを保証しなければなりません (MUST).
4.8.2. Time Values Derived from Transmission Parameters (伝送パラメータから派生した時間値)
ACK_TIMEOUT, ACK_RANDOM_FACTOR, およびMAX_RETRANSMITの組み合わせは再送信のタイミングに影響し, これが順番に実装が特定の情報項目を保持する必要がある期間に影響します. これらの派生した時間値を明確に参照できるようにするため, 次のように名前を付けます:
MAX_TRANSMIT_SPAN: Confirmableメッセージの最初の送信から最後の再送信までの最大時間. デフォルトの伝送パラメータの場合, 値は (2+4+8+16)*1.5 = 45秒, またはより一般的には:
ACK_TIMEOUT * ((2 ** MAX_RETRANSMIT) - 1) * ACK_RANDOM_FACTOR
MAX_TRANSMIT_WAIT: Confirmableメッセージの最初の送信から送信者が確認応答またはリセットの受信を諦める時間までの最大時間. デフォルトの伝送パラメータの場合, 値は (2+4+8+16+32)*1.5 = 93秒, またはより一般的には:
ACK_TIMEOUT * ((2 ** (MAX_RETRANSMIT + 1)) - 1) * ACK_RANDOM_FACTOR
さらに, ネットワークとノードの特性についていくつかの仮定をする必要があります.
MAX_LATENCY: データグラムが送信の開始から受信の完了まで要すると予想される最大時間. この定数は[RFC0793]のMSL (Maximum Segment Lifetime) に関連しており, これは "任意に2分と定義されています" ([RFC0793]用語集, 81ページ). これは必ずしもMAX_TRANSMIT_WAITより小さいわけではないことに注意してください. MAX_LATENCYはプロトコルがうまく機能する状況を記述することを意図しているのではなく, プロトコルが防御しなければならない最悪の状況を記述することを意図しているためです. 私たちも任意にMAX_LATENCYを100秒と定義します. ほとんどの構成で合理的に現実的であり, TCPの歴史的な選択に近いことに加えて, この値はMessage ID有効期間タイマーを8ビットで表現できるようにします (秒単位で測定した場合). これらの計算では, 送信方向が無関係であるという仮定はありません (つまり, ネットワークが対称的であるという仮定); 単に同じ値を両方向の最大値として合理的に使用できると仮定されています. そうでない場合, 以下の計算はわずかに複雑になるだけです.
PROCESSING_DELAY: ノードがConfirmableメッセージを確認応答に変換するのに要する時間. ノードは送信者がタイムアウトする前にACKを送信しようとすると仮定するため, 保守的な仮定として, これをACK_TIMEOUTと等しく設定します.
MAX_RTT: 最大ラウンドトリップタイム, または:
(2 * MAX_LATENCY) + PROCESSING_DELAY
これらの値から, プロトコル動作に関連する次の値を導出できます:
EXCHANGE_LIFETIME: Confirmableメッセージの送信を開始してから確認応答が期待されなくなるまでの時間, つまり, メッセージ交換に関するメッセージレイヤー情報をパージできます. EXCHANGE_LIFETIMEには, MAX_TRANSMIT_SPAN, 順方向の1つのMAX_LATENCY, PROCESSING_DELAY, および逆方向の1つのMAX_LATENCYが含まれます. 最後の待機期間 (ACK_TIMEOUT * (2 ** MAX_RETRANSMIT)またはMAX_TRANSMIT_SPANとMAX_TRANSMIT_WAITの差) がMAX_LATENCY未満になるように設定が選択されている場合, MAX_TRANSMIT_WAITを考慮する必要がないことに注意してください -- これはここで行われた選択です. MAX_LATENCYは現実世界で遭遇する可能性が低い最悪の場合の値であるためです. この場合, EXCHANGE_LIFETIMEは次のように単純化されます:
MAX_TRANSMIT_SPAN + (2 * MAX_LATENCY) + PROCESSING_DELAY
またはデフォルトの伝送パラメータで247秒.
NON_LIFETIME: Non-confirmableメッセージの送信からそのMessage IDを安全に再利用できる時間. NONメッセージの複数送信が使用されない場合, その値はMAX_LATENCY, または100秒です. ただし, CoAP送信者は, 特にマルチキャストアプリケーションの場合, NONメッセージを複数回送信する可能性があります. 転送中のNONメッセージを追跡しない実装は, より保守的な値を使用したい場合があります. 仕様はこれに特定の制限を定義していませんが, ほとんどの場合, 受信者による重複の信頼できる検出はMAX_TRANSMIT_SPANの時間スケールで行われます. したがって, この目的のために次の値を使用する方が安全です:
MAX_TRANSMIT_SPAN + MAX_LATENCY
またはデフォルトの伝送パラメータで145秒; ただし, すべてのメッセージタイプのMessage IDを期限切れにするために単一のタイムアウト値を使用したい実装は, EXCHANGE_LIFETIMEのより大きい値を安全に使用できます.
表3は, このサブセクションで導入された派生パラメータとそのデフォルト値を示しています.
+-------------------+---------------+
| name | default value |
+-------------------+---------------+
| MAX_TRANSMIT_SPAN | 45 s |
| MAX_TRANSMIT_WAIT | 93 s |
| MAX_LATENCY | 100 s |
| PROCESSING_DELAY | 2 s |
| MAX_RTT | 202 s |
| EXCHANGE_LIFETIME | 247 s |
| NON_LIFETIME | 145 s |
+-------------------+---------------+
表 3: 派生プロトコルパラメータ