ソケットサーバーとゲームサーバーを別々のプロセスにする必要がありますか？

単純な標準のクライアント/サーバーゲームを想定しています。サーバーの場合、クライアントからの接続とメッセージをリッスンし、ローカルソケットまたはstdinを介して実際のゲームサーバーを実行する別のプロセスにデータを送信する別のプロセスを用意する価値がありますか？

他のオプションは、両方のことを単一のプロセスで実行することです。着信メッセージをキューに入れ、正しい順序で実行することで、問題が停止することはありません。

2つの「アクティビティ」を分離するための追加リソースが実際に価値があるかどうか疑問に思っています。どのように決定すればよいですか？賛否両論を聞きたい。

API設計の観点から、複数の別個の通信プログラムを作成するか、1つだけを作成するかを決定するときの問題は、各プログラムが他のプログラムなしで有意義に機能できるかどうかです。答えは、プロジェクトと設定によって異なります。

できない場合は、考える価値がありません。明らかにそれらは非常に密接にリンクされているため、実際には独立したプロセスではありません。

可能であれば、また将来、それらを置き換えるためにさまざまなコンポーネントをドロップしたい場合は、OS提供のプロセス抽象化が役立つ可能性があります。

どのくらいそれが助けすることはしかし、あなたのハイテクスタックの残りの部分に依存します。たとえば、Erlangは既にプロセスとしてプロセスを内部的にモデル化しているため、OSプロセスに分割しても概念上の利点はあまり得られません。サーバーのこれらの部分を別の言語で書き直すことを考えている場合を除きます。C ++プログラムの内部コンポーネントは通常、より緊密に結合されているため、スワップアウトが困難です。したがって、それらを異なるOSプロセスに分割すると、そのような再配置を予測できる場合、後で作業を節約できます。

クライアントからの接続とメッセージをリッスンし、ローカルソケットまたはstdinを介して実際のゲームサーバーを実行する別のプロセスにデータを送信する別のプロセスを持つことは価値がありますか？

それが価値があるかどうかに答えるには、まず、専用のキューサービスを追加して解決しようとしている問題は何かを自問する必要がありました。それがその問題を解決するなら、それは価値があります。問題を解決できない場合、または最初に解決する問題がない場合は、おそらくそうではありません。

一部のサーバーが多層アーキテクチャを使用する理由を見てみましょう。

1. 負荷分散-ワークロードを複数のワーカーマシンに分散する場合は、負荷分散が有効です。同じマシン上に複数の並行ワーカープロセスを置くだけで解決したいボトルネックがあるプログラムの場合、長期的には実際にボトルネックを解決するのが最善ですが、短期的な回避策として、ワーカープロセスの生成が実用的です。
2. 特権の分離-チャットサーバーへのセキュリティ侵害がゲームサーバーへのアクセスを自動的に取得したり、その逆を行うことを望まないかもしれません。ゲームサーバーがゲーム内のチャットサーバーとは別の場合、ゲームサーバーとチャットサーバーを別々のセキュリティドメインに配置するように構成できます（たとえば、異なるユーザー、異なるアクセス権限、異なるプロセス制限などで実行）。
3. ゼロダウンタイムアップグレード-ゼロダウンタイムアップグレードを実現するには、複数の層を用意し、サービスのためにサーバーを停止したときに、その要求が同じ層の他のサーバーにリダイレクトされるようにシステムを構成する必要がありますサービス。
4. 制限の解除-ソケットの制限、ファイル記述子の制限、グローバルインタープリターロックなどに達した場合、複数のプロセスを実行することでその制限を回避できる場合があります。これを解決する別の方法は、制限を変更することですが、カーネルを再コンパイルする必要がある場合や、セキュリティまたはパフォーマンスに影響を及ぼす可能性があるため、必ずしも簡単ではありません。
5. リソースリークの制限-リソースをリークしないソフトウェアを作成しますが、完全にガベージ管理された言語でも、長期間のプロセスでは非常に困難であり、さらに悪いことに、開発環境でこれを複製するのは困難です。多層アーキテクチャを使用すると、一定の時間または数回のリクエストの後にゲームサーバーを強制終了して再起動し、サービスを中断することなくリソースの漏洩による損害を制限できます。

ラチェットフリークに同意します。あなたが単一のゲームサーバーを持っている限り、それはトラブルの価値はありません。

ただし、このアーキテクチャは、水平方向に拡大する必要がある場合に役立つことがあります。1つのゲームサーバーが十分ではなく、パフォーマンス上の理由で複数のゲームサーバーにゲームを分散する必要がある場合、「ソケットサーバー」アーキテクチャを非常に簡単に適合させて、ソケットサーバーを多くのバックエンドの1つに接続を自動的にルーティングするロードバランサーに変えることができますサーバ。

ただし、これが必要になるかどうかわからない場合は、この時点で2つの別個のサーバーアプリケーションを開発することは過剰なエンジニアリングになる可能性があります。

おそらくそうではありません。ほとんどの言語には、データを待機している間にブロックすることなく、一度に複数の接続を使用できる非同期ソケットがあります。これにより、「ソケットサーバー」部分がOS /カーネルに移行します。

明示的なソケットサーバーを使用すると、ローカルソケットを介してデータを渡すときに、余分なコピーがいくつか発生します。スケーラビリティを損なうことの1つは、必要のない余分なコピーです。