転送動作の構成

PlayFab Party のネットワーク機能には、ネイティブ プラットフォームのユーザー データグラム プロトコル (UDP) 機能を拡張し、リアルタイム・マルチプレイヤー・ゲームに最適なデータグラム転送機能が用意されています。

伝送制御プロトコル (TCP) は信頼性の高いストリームを提供し、UDP は信頼性の低いデータグラムを提供しますが、Party のネットワーク動作はデータグラムごとに構成できます。 PartyLocalEndpoint::SendMessage を使用して、ローカルの Party エンドポイントからリモートのエンドポイントにデータグラムを送信する場合、PartySendMessageOptions を指定して、目的の転送動作を微調整します。

次の機能が使用できます。

• 保証された配信 - GuaranteedDelivery フラグは、メッセージがすべてのターゲットに届くことを保証し、環境によるパケット損失を軽減するために、必要に応じて暗黙的にデータを再送信します。 このオプション フラグは、重要な状態情報を送信する場合に、常に宛先に配信される必要があり、そうでない場合はターゲットをネットワークから削除する必要がある場合に有効です。 既定のオプションは BestEffortDelivery で、UDP のような "送信して忘れる" 動作を提供します。
• 順次配信 - このローカル エンドポイントからターゲット エンドポイントに順次送信される他のメッセージに対して、メッセージの配信順序を指定します。 このオプション フラグは、特定の順序で宛先に届く必要がある状態の情報を送信する場合に使用します。 順次配信では、環境によるパケット損失や並び替えが発生した場合、ネットワーク効率がわずかに低下し、すべてのパケットを受信するまでの待機時間が長くなることがあります。 SequentialDelivery と GuaranteedDelivery を併用すると、先に順次送信したメッセージが届くのを待つ間に、ターゲット エンドポイントでメッセージがキューに登録される場合があります。 キューに登録されると、環境要因によるパケット損失や並べ替えの間に認識される待機時間が増えることがありますが、ターゲット エンドポイントには、送信された順序ですべてのメッセージが常に届きます。 このパフォーマンスのトレードオフは、TCP のようなプロトコルに共通するもので、ヘッドオブライン ブロッキングとも呼ばれます。
• 結合: Party ライブラリは、環境でサポートされている最大サイズを超える大きなメッセージを自動的に断片化して再構成するため、呼び出し元が断片化の管理を行う必要はありません。 多数の小さなデータグラムを送信する場合、結合すると 1 つのパケットにまとめられるため、帯域幅の効率が向上しますが、それに伴い待機時間が増える可能性があります。 CoalesceOpportunistically フラグ (既定値) を使用して送信すると、使用可能な場合はキューに登録された他のメッセージがメッセージと結合されますが、メッセージをすぐに送信できる場合は、それ以上待機しません。 AlwaysCoalesceUntilFlushed フラグを使用して送信すると、 PartyLocalEndpoint::FlushMessages が呼び出されるまで送信が遅延され、キューに登録されたメッセージがその時点で結合されて送信されます。

配信オプションとシーケンス オプションの組み合わせ

GuaranteedDelivery / BestEffortDelivery と SequentialDelivery/NonsequentialDelivery のオプションは独立しており、自由に組み合わせることができます。 それぞれの組み合わせによって、異なる動作が生じます。

ヘッドオブライン ブロックについて理解する

ヘッドオブライン ブロックは、配信順序の先頭にあるメッセージがまだ使用できない場合に発生します。 同じ順序内の後続メッセージは、受信側にすでに存在していても、アプリケーションに配信できません。

ヘッドオブライン ブロッキングに関連するオプションは SequentialDelivery であり、GuaranteedDelivery ではありません。 順次配信では、先行メッセージが後続メッセージをブロックする順序付けされた順序が作成されます。 GuaranteedDelivery は、欠落したメッセージをスキップするのではなく再送信する必要があるため、影響が誇張されることがあります。これにより、待機時間が長くなります。 BestEffortDelivery + SequentialDelivery では、欠落がスキップされ、順序が前方向に進むため、ブロックされる期間は短くなります。

NonsequentialDelivery メッセージは、順次メッセージによってブロックされることはありません。 2 つの配信モードは、互いに干渉しません。 再送信が保証された順次メッセージは、非順次メッセージの配信を遅延しません。

実践的なガイダンス

一般的なゲーム パターンでは、さまざまな種類のデータに対して複数の送信オプションが同時に使用されます。

• GuaranteedDelivery + SequentialDelivery: 順序付けと完全性が重要なゲーム状態の変更向け (インベントリの更新、一致状態の遷移など)。
• BestEffortDelivery + NonsequentialDelivery: 低待機時間が完全性よりも重要な、変化の速い状態向け (プレイヤーの位置、目的の方向など)。

順次メッセージと非順次メッセージは独立しているため、状態変更メッセージを再送信しても位置更新の配信は遅延しません。

複数の独立した順序

各ローカル エンドポイントは、独立した順序空間を表します。 1 つのローカル エンドポイントから特定のターゲット エンドポイントに送信されるすべての順次メッセージは、同じ順序保証を共有します。 その順序内でのヘッドオブライン ブロックは、同じ順序内の他の順次メッセージにのみ影響します。

同じ 2 つのデバイス間で複数の独立した順序付けされたストリーム (たとえば、ゲーム サブシステムごとに 1 つのストリーム) が必要な場合は、各デバイスに複数のローカル エンドポイントを作成できます (Party ネットワークの作成時に PartyNetworkConfiguration.maxEndpointsPerDeviceCount で指定された上限まで)。 異なるローカル エンドポイントから送信される順次メッセージには、互いに順序付けや配信の関係がありません。

ネットワーク統計情報とローカル キュー

メッセージ送信のオプションやネットワークの状態によっては、Party が送信前にメッセージをローカルでキューに入れる場合があります。 このローカル キューは、待機時間が発生しないように慎重に管理されています。 キューへの登録は、Party がプレイヤーのネットワークを過負荷にしないようにし、結合などの機能を適用できるようにするために必要です。

PartyNetwork::GetNetworkStatistics は、Party リレー サービスへの待機時間を含む、ネットワーク パフォーマンスの集計データを収集します。

PartyLocalEndpoint::GetEndpointStatistics は、特定のリモート エンドポイントのキュー登録とパケット損失に関する統計情報を可視化します。