Relay メッセージプロトコル#

プロジェクトで UTP または NGO を使用した Relay SDK を使用している場合は、Relay メッセージプロトコルが既にサポートされています。ただし、代替のエンジンやネットワーキングソリューションを使用したい場合は、まず Relay メッセージプロトコルを実装する必要があります。Relay メッセージプロトコルの仕様を使用して、Relay メッセージプロトコルを実装してください。

Relay メッセージプロトコルでは、フィールドの値がビッグエンディアンの順序で表現されることを前提としています。これは “ネットワークオーダー” とも呼ばれ、最も重要なバイトが最初に来ます。

メッセージは認証されません。ただし、HMAC 署名が使用される BIND メッセージ は例外です。

プレイヤー が接続してメッセージをリレーできるは、同じ Unity プロジェクトの同じ環境から参加している他のプレイヤーのみとなります。Unity 環境間をまたいだ通信の試行は Relay によって拒否されます。

すべてのメッセージには、標準のヘッダーと、メッセージ固有の本文があります。標準ヘッダー と メッセージ本文 を参照してください。

メッセージの種類#

承諾モードの種類#

承諾モードは、クライアント からの接続リクエストを Relay サーバー がどのように処理するかを定義するものです。

Relay では、AUTO 承諾モードのみがサポートされています。AUTO モードの接続は、Relay サーバーのキャパシティを超えていなければ (接続数が許容される最大接続数を超えていなければ)、自動的に承諾されます。

標準ヘッダー#

すべてのメッセージタイプには共有の標準ヘッダーがあり、そのヘッダーには署名、Relay メッセージプロトコルのバージョン、およびパケットの本体に含まれるメッセージが含まれています。

以下の表は、標準ヘッダー内にある各フィールドについて説明したものです。

メッセージ本文#

BIND メッセージ#

BIND メッセージは、特定の割り当てに対応するクライアントの IP アドレスとポートのマッピングを作成するために、クライアントから Relay サーバーに送信されます。このメッセージは、クライアントの ID を確認するために認証されます。

割り当てサービス から受信した応答には、クライアントが BIND メッセージを認証するために必要な情報が含まれています。BIND メッセージに対する割り当てサービスからの応答は、バインディングの状態を示します。

クライアントは、クライアントの IP アドレスとポートが変更されていない限り、同じ BIND メッセージを送信できます。例えば、クライアントが IP アドレスまたはポートを変更した後の次の接続で BIND メッセージを送信する場合、Nonce 値は以前に指定された値よりも大きくなければなりません。

以下の表は、BIND メッセージ内にある各フィールドについて説明したものです。

セキュリティ

HMAC には、割り当てサービス から返された秘密鍵で署名する必要があります。HMAC が無効である場合、Relay サーバーは BIND message メッセージを暗黙的に拒否します。

また、Relay サーバーは悪意のある攻撃者によるメッセージリプレイ攻撃を軽減するために、nonce 値を検証します。nonce が無効であると判断した場合、Relay サーバーはメッセージを暗黙的に拒否します。クライアントが BIND message メッセージを使用して初めて Relay サーバーにバインドする場合は、nonce 値を 0 にできます。

BIND_RECEIVED メッセージ#

Relay サーバーは、リクエスト元クライアントが BIND message メッセージを通じて自身に正常にバインドされたことを確認するために、そのクライアントに BIND_RECEIVED メッセージを送信します。確認を受信した後、リクエスト元クライアントは CONNECT_REQUEST message メッセージを使用してターゲットクライアントとの通信を開始できます。

PING メッセージ#

PING メッセージは、クライアントタイムアウト をリセットして、クライアントと Relay サーバー のバインディングを維持するためのシンプルなメッセージです。Relay サーバーは、10 秒間アクティビティがないと自動的にクライアントを切断します。このクライアントに関連して Relay サーバーが受信した (送信者または受信者としての) メッセージがある場合、このタイムアウトはリセットされます。メッセージの頻度が低いゲームでは、PING メッセージを使用してクライアントが切断タイマーをリセットできます。

各 PING メッセージには、クライアントの割り当て ID と、メッセージを識別するための任意の番号が含まれています。

Relay サーバーは、クライアントから PING メッセージを受信すると、それを変更せずにパケットをクライアントに送り返します。そのため、PING メッセージは接続状態を確認し、ラウンドトリップ時間を測定するために使用できます。

割り当て ID が期限切れになった場合、Relay サーバーからエラーメッセージは返されません。

以下の表は、PING メッセージ内にある各フィールドについて説明したものです。

CONNECT_REQUEST メッセージ#

CONNECT_REQUEST メッセージは、ターゲットクライアントへの接続を確立するために、リクエスト元クライアントから Relay サーバーに送信されます。リクエスト元クライアントが接続しようとしているターゲットプレイヤー (またはターゲットクライアント) は ToConnectionData によって表され、Relay サーバーはこれを解読してどのプレイヤーと接続するかを判断します。

以下の表は、CONNECT_REQUEST メッセージ内にある各フィールドについて説明したものです。

ACCEPTED メッセージ#

Relay サーバーは、ターゲットクライアントへの接続が成功した後に、リクエスト元クライアントに ACCEPTED メッセージを送信します。

以下の表は、ACCEPTED メッセージ内にある各フィールドについて説明したものです。

DISCONNECT メッセージ#

DISCONNECT メッセージは CONNECT_REQUEST ハンドシェイクの逆で、クライアントが他のクライアントから切断するためのメッセージです。クライアントは、DISCONNECT メッセージを Relay サーバーに送信することで、接続した他のクライアントから 切断 することができます。

Relay サーバーは、このメッセージを受信すると、指定された割り当て ID をリクエスト元クライアントの接続済みプレイヤーリストから削除します。また、Relay サーバーは DISCONNECT リクエストをホストクライアントに転送します。これにより、そのクライアントは接続済みプレイヤーのマップを更新して、リクエスト元クライアントの割り当て ID を削除できるようにします。

その後、Relay サーバーは確認として DISCONNECT メッセージをクライアントに返します。メッセージ本文内の割り当て ID のいずれかが無効である場合、Relay サーバーは代わりに ERROR message メッセージを送信します。

クライアントが切断されると、Relay サーバーはそのクライアントの割り当て ID 宛に送信されたすべての RELAY メッセージ を拒否するようになります。切断されたクライアントは、CONNECT_REQUEST message メッセージを使用して再度接続を確立できます。

以下の表は、DISCONNECT メッセージ内にある各フィールドについて説明したものです。

RELAY メッセージ#

RELAY メッセージを使用すると、クライアントは互いの IP アドレスとポートを意識することなく、任意のバイトのペイロードを含んだメッセージを相互に送信することができます。

Relay サーバーは、クライアント間で RELAY メッセージが送信される前に、パケットの送信元クライアントが以前に BIND message を通じて FromAllocationID として認証されていることを確認します。クライアントが以前にバインドされていない場合、Relay サーバーは ErrClientPlayerMismatch ERROR メッセージ を返します。

Relay サーバーはまた、2 つのクライアントの間に、以前の CONNECT_REQUEST の交換を通じて確立された接続があることを確認します。クライアントが接続されていない場合、Relay サーバーは ErrNotConnectedERROR message を返します。

すべての検証が成功した場合、Relay サーバーはメッセージ全体を ToAllocationID にそのまま送信します。Relay サーバーは FromAllocationID には確認メッセージを送信しません。

以下の表は、RELAY メッセージ内にある各フィールドについて説明したものです。

CLOSE メッセージ#

CLOSE メッセージは、クライアントが Relay サーバーからバインドを解除し、割り当てを解除するための冪等性のあるメッセージです。クライアントは、ゲームセッションを終了する際、またはゲームクライアントを閉じる際に、Relay サーバー に CLOSE メッセージを送信する必要があります。クライアントは、Relay サーバーに対する自身のバインディングのみを閉じることができます。他のクライアントのバインディングを閉じることはできません。

クライアントは、成功確率を高めるために CLOSE メッセージを複数回送信する必要があります。CLOSE メッセージは冪等性があるため、クライアントがすでに 切断されている 場合でも、Relay サーバーから ERROR メッセージ が送信されるリスクはありません。

CLOSE メッセージは、割り当てを円滑に終了させるためのベストエフォートであり、成功を保証するものではありません。Relay サーバーはタイムアウトでクライアントを割り当て解除できるので、クライアントの割り当てを解除するために必ずしも CLOSE メッセージを必要としません。

CLOSE メッセージを送信するクライアントは、以前の BIND リクエスト を通じて Relay サーバーにバインドされている必要があります。クライアントが Relay サーバーにバインドされていない場合 (またはクライアントの IP アドレスが変更されている場合)、Relay サーバーはメッセージを暗黙的に拒否します。意図しない割り当てタイムアウトを防ぐために、PING メッセージを使用してください。

以下の表は、CLOSE メッセージ内にある各フィールドについて説明したものです。

ERROR メッセージ#

Relay サーバーは、クライアントにエラーが発生したことを通知するために、ERROR メッセージを厳格に使用します。

以下の表は、ERROR メッセージ内にある各フィールドについて説明したものです。

エラーコード

以下の表は、Relay サーバーがクライアントに送信できるエラーメッセージをそれぞれ説明したものです。