PartySendMessageOptions

[アーティクル]
07/11/2023

メッセージの送信方法を制御するためのオプション。

構文

enum class PartySendMessageOptions  : int32_t  
{  
    Default = 0x0000,  
    GuaranteedDelivery = 0x0001,  
    BestEffortDelivery = 0x0000,  
    SequentialDelivery = 0x0002,  
    NonsequentialDelivery = 0x0000,  
    CopyDataBuffers = 0x0000,  
    DontCopyDataBuffers = 0x0004,  
    CoalesceOpportunistically = 0x0000,  
    AlwaysCoalesceUntilFlushed = 0x0008,  
    RequireTimelyAcknowledgement = 0x0000,  
    AllowLazyAcknowledgement = 0x0010,  
}

定数

定数	説明
既定値	既定の PartySendMessageOptions を使用します。規定のオプションは、BestEffortDelivery、NonsequentialDelivery、CopyDataBuffers、CoalesceOpportunistically、RequireTimelyAcknowledgement です。
GuaranteedDelivery	メッセージがすべてのターゲットに配信されていることを確認し、必要に応じて再送信します。このオプションフラグは、ターゲットエンドポイントが破壊されない限り、環境によるパケットロスに関わらず、メッセージが各ターゲットエンドポイントに到着することを保証します。パケット転送は必要に応じて再試行されます。このオプションフラグは、重要な状態情報を送信する場合に、常に宛先に配信される必要があり、そうでない場合はターゲットをネットワークから削除する必要がある場合に有効です。冗長性を持たないメッセージコンテンツや、損失した場合に補間/推定する機能がないメッセージコンテンツと共に使用します。パケットの再送信が必要な場合は、帯域幅の使用量が増加する可能性があります。配信を単独で保証することは、特定の配送注文の保証を意味するものではありません。順序付けを強制するには、SequentialDelivery オプションフラグを使用します。
BestEffortDelivery	メッセージのベストエフォートを送信し、パケット損失を無視します。このオプションフラグは、メッセージの送信を 1 回だけ要求します。環境パケットの損失が発生した場合、転送は再試行されず、アプリケーションはメッセージの不在を処理するように準備する必要があります。このオプションフラグは、常に更新されており、すべての更新プログラムが到着する必要がない情報に適しています。冗長性が既にあるメッセージコンテンツ、または失われた場合に補間/補間する機能があり再送信する余分な帯域幅の価値がないメッセージコンテンツと共に使用します。これは、GuaranteedDelivery オプションフラグが指定されていない場合の既定値です。
SequentialDelivery	このローカルエンドポイントから順番に送信されたターゲットエンドポイントに送信された他のメッセージを基準にして、メッセージを配信します。 SequentialDelivery では、異なるローカルエンドポイントから、または異なるターゲットエンドポイントに送信されるメッセージの順序に関する保証はありません。各エンドポイントペアリングは、個別のシーケンス空間と見なす必要があります。非シーケンシャルメッセージに関連するシーケンシャルメッセージの順序に関する保証はありません。このオプションフラグは、特定のシーケンスで宛先に到達する必要がある状態情報に対して適切に機能します。これは、ネットワークの効率が若干低下し、環境によってパケット損失や順序変更が発生した場合に受信を少し待つ可能性がある場合でも有効です。 GuaranteedDeliveryで SequentialDelivery を使用すると、以前に送信されたシーケンシャルメッセージが到着するのを待っている間に、メッセージがターゲットエンドポイントでキューに入れられます。このため、環境によるパケット損失や並び替えが発生した場合、遅延が長くなると感じられる場合がありますが、ターゲットエンドポイントでは、常にすべてのメッセージが、送信されたときと同じ順番で表示されます。 SequentialDeliveryを BestEffortDelivery と共に使用すると、ターゲットエンドポイントに到着し、後のシーケンシャルメッセージが既に配信されている場合、メッセージが破棄される可能性があります。ターゲットエンドポイントでは常にシーケンスが前方に表示されますが、そのシーケンスにギャップがある可能性があります。古いメッセージは、新しいメッセージの後には配信されません。
NonsequentialDelivery	メッセージが到着したらすぐにターゲットに配信します。非シーケンシャル配信オプションを使用して送信されたメッセージは、他のメッセージ (シーケンシャルまたは非シーケンシャル) に対して配信される順序に関する保証を提供しません。メッセージは到着次第すぐに受信側に届けられますが、パケット損失または環境による順序の変更があった場合、送信時と同じ順序で受信されない可能性があります。このオプションフラグは、任意の順序で安全に処理できるメッセージや、独自の固有の順序情報が既に存在するメッセージ、およびネットワーク効率を最大化し、待ち時間を最小限に抑える場合に適しています。これは、SequentialDelivery オプションフラグが指定されていない場合の既定値です。
CopyDataBuffers	指定されたデータバッファーのコピーを後続の転送用に作成するようにパーティライブラリに指示します。指定された PartyDataBuffer 構造体内のメモリコンテンツがコピーされるため、呼び出し元は、PartyLocalEndpoint::SendMessage() が返された後バッファーを保持する必要はありません。これは、DontCopyDataBuffers オプションフラグを使用するよりも便利ですが、効率が若干低くなります。これは、DontCopyDataBuffers オプションフラグが指定されていない場合の既定値です。
DontCopyDataBuffers	提供されたデータバッファーを直接使用し、ライブラリが不要になるまで呼び出し元がメモリを有効な状態に保つことをパーティライブラリに通知します。指定された PartyDataBuffer 構造体によって参照されるメモリはコピーされませんが、代わりに所有権は一時的に Party ライブラリに転送されるため、転送プロセス中に追加のコピーオーバーヘッドなしでメモリに直接アクセスできます。ライブラリでメモリバッファーが不要になり、PartyDataBuffersReturnedStateChange を介して所有権が転送されるまで、メモリバッファーが有効で変更されていないことを確認するのは、呼び出し元の責任です。これは効率的ですが、CopyDataBuffers オプションを使用するよりも便利ではありません。 PartyDataBuffer 構造体自体は、PartyLocalEndpoint::SendMessage() 呼び出しが返された後も有効であり続ける必要はなく、参照するメモリのみが有効となります。
CoalesceOpportunistically	このメッセージを他のキューに入れられたメッセージと結合する必要がありますが、待機していない場合は転送を遅延しないように指定します。複数のメッセージを 1 つのパケットにまとめることで、帯域幅の効率を最大限に高めることができます (パケットあたりのオーバーヘッドを削減できます) が、合体させるためにメッセージの送信を遅らせると、メッセージの遅延が発生する可能性があります。このフラグを使用して送信すると、他のキューに入れられたメッセージがある場合、パーティーライブラリはメッセージを結合しますが、存在しない場合はメッセージが増えるのを待つのではなく、このメッセージをすぐに送信できます。通常、ネットワークの更新を 1 つの定期的なメッセージにバッチ処理する場合は、このフラグを使用します。このメッセージは、他のメッセージと同じ時刻にキューに登録される可能性が高く、遅延しても帯域幅の効率が向上しません。このフラグは、メッセージが直ちに送信を開始することを保証するものではありません。接続の品質または受信者の応答性が現在追加データの送信をサポートしていないように見える場合は、次の送信機会を待つメッセージがキューに入れられます。これは、AlwaysCoalesceUntilFlushed オプションフラグが指定されていない場合の既定値です。
AlwaysCoalesceUntilFlushed	このメッセージを常に他のメッセージと結合し、PartyLocalEndpoint::FlushMessages() 呼び出しが送信を開始することを想定するように指定します。複数のメッセージを 1 つのパケットにまとめることで、帯域幅の効率を最大限に高めることができます (パケットあたりのオーバーヘッドを削減できます) が、合体させるためにメッセージの送信を遅らせると、メッセージの遅延が発生する可能性があります。このフラグを使用して送信すると、PartyLocalEndpoint::FlushMessages() が呼び出されるまで、パーティーライブラリは常にメッセージの結合を優先し、送信を遅延させます。通常、同じ更新ループ内の同じターゲットに多数の小さなメッセージを送信し、完全な更新ループの反復が完了したときに Party ライブラリに明示的に通知する場合は、このフラグの使用を検討してください。このフラグを使用しても、明示的な PartyLocalEndpoint::FlushMessages() 呼び出しを必要とせずにメッセージの送信が開始される可能性があるシナリオがあります。これは、他の理由で既に送信されているキューに入れられた他のメッセージがあり、パケットにこのメッセージを含める領域がある場合に発生する可能性があります。同様に、完全なパケットを送信するのに十分なメッセージデータバイトが存在し、これ以上結合できない場合は、パケットが送信されます。すべてのメッセージの送信が既に開始されているときに PartyLocalEndpoint::FlushMessages() を呼び出すことは問題ありません。
RequireTimelyAcknowledgement	このメッセージを (必要に応じて) 適切なタイミングで確認する必要があることを示します。受信者は、配信の成功または失敗を送信者に通知するメッセージの受信を確認し、GuaranteedDelivery オプションフラグを使用して送信されたメッセージを含むパケットを破棄した再試行などを行うことができます。受信確認は、一般的な双方向通信の一部としてパケットに対してピグバックされることが多いですが、パケットが戻り方向に流れていなければ、このフラグは、受信確認パケットが送信者に通知する前に、ピッグバックの機会に対して内部的に管理された小さなタイムアウトのみを待機するようにターゲットエンドポイントに指示します。その専用パケットは余分なオーバーヘッドを消費しますが、送信者が必要な再試行を発行するためのタイムリーな状態を取得します。ほとんどの保証された配信メッセージには、このフラグを使用することをお勧めします。待ち時間が重要なメッセージに適しています。また、双方向の保証された配信送信パターンが頻度が低い場合や予測できない場合にも適しています。これは、AllowLazyAcknowledgement オプションフラグが指定されていない場合の既定値です。このフラグは、GuaranteedDelivery オプションフラグが指定されていない場合は無視されます。
AllowLazyAcknowledgement	緊急ではなく、都合の良いときにこのメッセージを確認できることを示します。受信者は、配信の成功または失敗を送信者に通知するメッセージの受信を確認し、GuaranteedDelivery オプションフラグを使用して送信されたメッセージを含むパケットを破棄した再試行などを行うことができます。受信確認は、一般的な双方向通信の一部としてパケットに対してピグバックされることが多いですが、パケットが戻り方向にフローしていない場合、このフラグは、受信確認パケットが送信者に通知することなく、ピグバックの機会を待つようターゲットエンドポイントに指示します。これは、送信者が必要な再試行のために状態を確認するのを遅らせますが、専用パケットで消費される余分なオーバーヘッドを避けることができます。このフラグは、「ファイアアンドフォーゲット」で、遅延を気にしない配信メッセージを保証する場合に使用してください。また、双方向の送信パターンが頻繁に発生する場合には、オーバーヘッドを減らすことができます。このフラグは、GuaranteedDelivery オプションフラグが指定されていない場合は無視されます。

要件

ヘッダー: Party.h

次の方法で共有

PartySendMessageOptions

構文

定数

要件

関連項目

フィードバック

その他のリソース