java - RPCを使用したサーバー上のマルチプレイヤーカードゲーム

Question

基本的に、Java、Python、またはC ++スクリプトをサーバーで実行し、プレーヤーインスタンスをリッスンして、参加、呼び出し、賭け、フォールド、カードのドローなどを行い、プレーヤーが離れたり切断したりするときのタイムアウトを設定する必要があります。

基本的に、これらの各アクションを小さなリクエストにして、プレーヤーがゲームサーバーと通信する同じマシン上のプロセスになるか、ネットワーク全体のマシンになるようにします。

メッセージングのセキュリティは問題ではありません。これは学習/研究/楽しみのためです。

私の優先事項：

1. プレーヤーが切断したことを検出するための優れたスキームを用意しますが、起動/手を失う前にネットワーク遅延などを考慮することもできます。
2. スピード。私はこれらの何百万ものハンドをできるだけ速くプレーするつもりです。
3. 共有サーバーインスタンスで実行します（ポートまたはルートが必要なものへのアクセスが制限されている可能性があります）

私の質問：

1. ポートでリッスンするか、ソケットまたはHTTPポート80 apacheリスニングスクリプトを使用しますか？（私はこれらの違いについて少しぼんやりしています）。
2. うまくいくための良いフレームワークはありますか？
3. メッセージタイプ？JSONまたはProtocolBuffersを考えています。
4. それを速くする方法は？

みんなありがとう-いくつかのポインタと提案を探しています。それを学ぶことはたくさんのきちんとしたことでクールな問題だと思います。

Answer 1

フレームワークに関する限り、Ginkgoはネットワークサービスを構築することを約束しているように見えます（これはあなたがしていることです）。Pythonは非常に単純であり、geventによって有効化された非同期性により、通常はコールバックについて心配することなく、非同期の処理を実行できます。geventコアを使用すると、多くのビルディングブロックにアクセスすることもできます。

多くのサービスがポートを介して通信するのではなく、1）RabbitMQや0mqなどの優れたメッセージキュー、または2）Zookeeperなどの分散調整サーバーのいずれかを調べることができます。

そうは言っても、特に基本に精通していない場合、あなたが目指すことは困難です。それらの基本について学ぶことは価値のある努力です。

最初は速度を気にしないでください。それを機能させてから、スケーリングします。もちろん、将来のスケーリングを容易にする方向性もあります。特にZookeeperは、水平方向にスケーリングするための実装が簡単なプリミティブを提供します（つまり、複数のワーカーが負荷を共有します）。特に、Zookeeperレシピブックとそれに対応するPython実装（geventベースのクライアントライブラリであるkazooの提供）を参照してください。

「高速」とは、独自の開発時間を最適化することも意味することを忘れないでください。これにより、反復が速くなり、開発環境の呪いが減ります。したがって、Pythonを使用すると、すぐに起動して実行でき、CPU時間やメモリ使用量を本当に制限し始めた場合は後で最適化できます。（この特定のアプリケーションを使用すると、ネットワークIOにバインドする可能性がはるかに高くなります。）

Answer 2

他に何か？たぶんあなたの質問に合うコーヒー一杯:-)

ゼロから質問に答えるには、基本的なTCP / IPネットワーキングからスケーラブルなアーキテクチャに至るまでのトピックを含む数冊のテキストが必要になりますが、それでも私はあなたにいくつかの方向性を与えるようにします。

質問：

1. ポートでリッスンするか、ソケットまたはHTTPポート80 apacheリスニングスクリプトを使用しますか？（私はこれらの違いについて少しぼんやりしています）。

これらのそれぞれの定義が明確でない場合は、「できるだけ速く何百万ものハンドをプレイする」サービスを実装するように設計するのは少しうーん、行き過ぎだと思いますか？しかし、彼らが「無知は至福である」と言うので、それがあなたを止めさせないでください。

1. うまくいくための良いフレームワークはありますか？

あなたのプロジェクトはNode.jsの良い候補だと思います。Node.jsは比較的スケーラブルであり、そのスケーラビリティに必要な複雑さを隠すのに優れていることが主な理由です。Node.jsには欠点があります。Googleで「Node.jsスケーラビリティの批判」を検索するだけです。より汎用的なフレームワークを使用するのとは対照的に、Node.jsに対する主なポイントは、スケーラビリティが難しく、それを回避する方法がないことです。Node.jsは非常に高レベルで具体的であるため、問題を解決するためのオプションが少なくなります。もう1つの欠点は、Node.jsがJavascriptであり、JavaやPhytonではないことです。

1. メッセージタイプ？JSONまたはProtocolBuffersを考えています。

クライアントとサーバーの間に大量のトラフィックが発生することはないと思うので、JSONが普及しているという理由だけで、JSONを使用するかどうかは問題ではありません。

1. それを速くする方法は？

本当の問題は、それをどのようにスケーラブルにするかです。人間対人間のカードゲームの実行は計算量が多くないため、計算の限界に達する前にI/O容量が不足する可能性があります。これらの制限を克服するには、マシン全体に負荷を分散させます。マルチプレイヤーゲームで行う一般的な方法は、同一のゲームサーバーへのリンクを提供するリストサーバーを用意することです。各サーバーには、プレイヤーが使用できるスロットの数が事前定義されています。これは、ブローカーマシンがクライアントのビジー状態に基づいてワーカーマシンをクライアントに割り当てる場合の、ブローカーワーカーアーキテクチャのバリエーションです。ゲームでは、ユーザーは自分のサーバーを選択して、友達と遊ぶことができるようにしたいと考えています。

関連している：

1. プレーヤーが切断したことを検出するための優れたスキームを用意しますが、起動/手を失う前にネットワーク遅延などを考慮することもできます。

これは人間の時間スケール（ミリ秒ではなく秒）であるため、クライアントは、たとえば30秒のセッションタイムアウトを使用して、たとえば10秒ごとにキープアライブを送信する必要があります。キープアライブは、アプリケーションプロトコルのJSONメッセージであり、HTTPではなく、下位レベルでフレームワークによって処理されます。フレームワーク自体は、複数のhttpセッション（要求/応答）が同じ接続を通過できるようにするHTTP 1.1接続管理/プーリングを提供する必要がありますが、クライアントが常に接続されている必要はありません。これは信頼性と速度の間の適切な妥協点であり、ターンベースのカードゲームには十分なはずです。

Answer 3

正直なところ、私は古典的なランプから始めます。標準のApacheサーバーとmysqlデータベースを取得し、Pythonスクリプトをcgi-binディレクトリに配置します。HTTPではなくJSONを送受信しているという事実は、大きな違いはありません。

もちろん、これは明らかに最も柔軟でスケーラブルなソリューションにはなりませんが、実際の問題にできるだけ早く直面する必要があります。

あなたが遭遇しようとしている最初の問題はゲームの状態です。あなたは共有状態がないと主張しますが、それは正しくありません—デッキのカード、テーブルの賭け、それが順番になります—それはすべての状態であり、複数のプレーヤー間で共有され、サーバー上で管理されます。これらのコマンドのいずれかが他にどのように機能するでしょうか？したがって、CGIスクリプトの個別のインスタンス間で状態を共有するための何らかの方法が必要です。古典的な解決策は、データベースに状態を保存することです。

もちろん、そもそもユーザーセッションにも対処する必要があります。詳細は、選択するセッション管理スキームによって異なりますが、大きな問題は、切断/タイムアウトを下位レベルからアプリケーションレベルにどのように伝播するかです。誰かが$20をテーブルに置いてから切断するとどうなりますか？考えられるすべてのユースケースを検討する必要があります。

次に、スケーラビリティについて考える必要があります。何百万ものゲームが欲しいですか？すべてのゲーム状態を含む単一のデータベースがある場合は、必要な数のWebサーバーをその前に置くことができます。JohnDoeはserver1にあり、Joe Schmoeはserver2にある可能性がありますが、同じゲームにある可能性があります。一方、同じゲーム内の人々を同じサーバー上で強制的に会わせる方法がある限り、サーバーごとに個別のデータベースを作成できます。どちらがより理にかなっていますか？いずれにせよ、サーバー間でどのように負荷分散しますか。（すべてをビジー状態に保つだけでなく、4人のプレーヤーがすべて準備ができているという状況を避けたいだけでなく、3つの異なるサーバー上にいるため、お互いにプレイできません…）。

このプロセスの最終結果は、期待した容量の1％で実行され、保守方法がわからないサーバーの大混乱になります。しかし、問題の領域をより詳細に検討し、サーバー開発の基本も学習します。どちらも長期的にはおそらくより重要です。

時間があれば、次にすべてを捨てて、カスタムTCPプロトコルを設計し、Twistedのようなサーバーを実装し、ゲームの状態をメモリに保持し、簡単なカスタムを作成することで、すべてを最初から書き直します。標準のロードバランサーの代わりにブローカー。