0

Azure クラウドで実行されているゲーム サーバーに取り組んでいますが、ちょっとした障害にぶつかりました。ゲーム自体は一連のワールドに基づいており、それぞれが異なるワーカー ロールで実行され、個別の地形データを持っています。ただし、これらのワールドを管理するために使用するメインのワーカー ロールを作成して、ワールド ロールを開始し、正しいマップをロードするように設定する方法がわかりません。また、クライアントがランダムな他の世界ではなく、要求された世界に接続することを確認する方法もわかりません。

誰かが私を正しい API にリンクして、これを行うことができれば幸いです。

4

2 に答える 2

0

ソリューションでは、複数の worker ロールを作成し、特定のポートを持つ各ロールのエンドポイントを作成できます (同じポートを異なるロールに使用することはできません)。エンドポイントの負荷を分散させるために、入力エンドポイントを使用していることに注意してください。

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="CloudPathDemo" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2012-05.1.7">
  <WorkerRole name="WorkerMainWorld" vmsize="Small">
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="tcp" port="50000" />
    </Endpoints>
  </WorkerRole>
  <WorkerRole name="WorkerWorld1" vmsize="Small">
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="tcp" port="50001" />
    </Endpoints>
  </WorkerRole>
  <WorkerRole name="WorkerWorld2" vmsize="Small">
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="tcp" port="50002" />
    </Endpoints>
  </WorkerRole>
  <WorkerRole name="WorkerWorld3" vmsize="Small">
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="tcp" port="50003" />
    </Endpoints>
  </WorkerRole>
</ServiceDefinition>

たとえば、クライアントまたは「メイン」ワーカー ロールをワールド 3 に接続する場合は、たとえばmygame.cloudapp.net:50003に tcp リクエストを送信します。

「地形管理」を何らかの形で動的にしたい場合は、トピックとサブスクリプションを使用できます。各 WorkerRole に 1 つのトピックがあり、各インスタンスが 1 つのサブスクリプションであると仮定しましょう。次に、特定のトピックにメッセージを送信して、その WorkerRole でどのワールドをプロビジョニングする必要があるかを伝えると、その WorkerRole の各インスタンスがそのメッセージを受け取り、必要なプロビジョニングを行います。もちろん、後で (スケールアップしたときに) インスタンスが追加される可能性があることを考慮する必要があるため、これらのインスタンスは、どのワールドをプロビジョニングする必要があるかを知る必要もあります (例のテーブル ストレージからリストを読み取ることによって)。

于 2012-09-14T08:33:11.150 に答える
0

私のお勧めは、世界のエンドポイント (必要に応じてプロキシ) であるマスター/コントローラーを作成することです。すべての接続がそこに到達し、それらをバックエンドの世界固有のサーバーに直接ルーティングします。この接続は非常に薄い可能性があるため (接続が確立されたら、IP トンネルだけを考えています)、遅延が大きくなることはありません。

このアプローチにはいくつかの落とし穴があります。

プロキシは、限られた数のアクティブな接続しか処理できません。したがって、これを監視し、トラフィックをセカンダリ プロキシ/リレーにルーティングする方法が必要です。Windows Azure のビルトイン ロード バランサーは、これに適しています。アクティブな接続を監視し、その情報を使用してスケーリング動作を制御するだけで済みます。

さらに、アイドル状態の接続は Windows Azure ロード バランサーによって強制終了されるため、プロキシは接続が強制終了されたことを検出して、それらのリソースを解放して別の接続にサービスを提供できるようにする必要があります。

このアプローチの利点は、ワールド サーバーがオフラインになったり移動したりした場合 (そしていずれそうなることになるでしょう)、プロキシがワークロードがどこに移動したかを検出し、それに応じて接続をシフトすることで、外部ユーザーには見えないようにすることです。 .

さて、これらすべてに対しても機能する別のアプローチが 1 つあります。Windows Azure サービス バス リレー。各「ワールド」サーバーは、サービス バス上に独自のエンドポイントを持ち、クライアントが接続を要求すると、制御する「プロキシ」に到達し、要求されたサーバーのエンドポイントを取得します。クライアントとサーバーが直接接続をネゴシエートし、リレーの遅延を減らすハイブリッド接続を有効にすることで、これをさらに一歩進めることができます。また、サービス バス エンドポイントは、公開された場所であるため、マシン固有のアドレス指定可能性に関する問題を解決します。

于 2012-09-14T12:44:36.130 に答える