IOCP、kqueue、epoll ...それはどれほど重要ですか？

mmoサーバーを設計しているときに、多くの接続を処理するときにSelectがいかに非効率的であるかについて多くの疑問を耳にしました。 iocp（windows）、kqueue（freebsd）、またはepoll（linux）に切り替えてください。実際、読み書きするために多数の接続を選択することは選択が非効率的です。カーネルは毎回selectによって渡されるソケット番号のセットを毎回ポーリングしなければならないため、上海ではChen Yuの場合、これは悪魔の村の戦略と呼ばれます。何度も何度も尋ねた - 村に悪魔を？ '、'悪魔は村に入りますか？ ' ...多くのCPU時間が費やされています。 （さらに、Windowsでは、64の不吉な制限があります。）

kqueueを使うと、これらは警戒する人になり、悪魔が来たときには通知を受けることができ、効率は自然に高いです。たくさんあります。しかし、最近私は再考していますあなたは本当にこれらに基づいてサーバーを構築する必要がありますか？

形成されたばかりのアイデアの1つは次のとおりです。

後で簡単に表現できるように、外部接続とゲームロジックの処理を2つのサーバーに分散して処理します。一時的にそれほど厳密ではありません。前者は接続サーバと呼ばれ、後者は論理サーバと呼ばれます。

複数の接続からのデータをまとめるだけで、サーバーへの接続は非常に簡単になります。同時接続の総数が65,536を超えないと仮定すると、各接続のデータパケットに2バイトのヘッダーを追加するだけで済みます。この接続サーバーは、単一の接続を介して論理サーバーと通信します。

最も効率的な方法でデータを処理する接続サーバーがあり、その論理は単純で、コード量は非常に少ないです。論理サーバーには外部接続が1つしかありません。処理方法に関係なく、遅くなることはありません。

さらに、このメソッドを拡張することもできます。私たちのロジックが10 Hzの周波数でロジックを処理するとしましょう。接続サーバに集約データを10Hzのパルスで定期的に送信させ、最初に長さメッセージを送信してからデータパケットを送信します。 1つのパルスに外部データがない場合でも、少なくとも1つの長さ情報を送信することが厳密に保証されています。さらに、接続サーバーは、論理サーバー処理の容量を超えるデータを送信しないように、各パルスの合計データフローを制御する必要もあります。

そのため、論理サーバーはrecvを呼び出してデータをブロックすることができ、selectが保存されている場合でも可能です。データが本当に受信側によってブロックされているかどうかに関しては、接続サーバーのロジックによって保証されています。

同僚に話しかけたときに受信をブロックすることになると、彼はこれの信頼性について真剣に心配していて、誤って論理サーバーをシステムコールに入れたくありませんでした。彼は考えられる多くの事故を挙げたが、私は個人的にあまり心配しないで、そしてここでもっと説明したくない。もちろん、私はこれを設計しました。主にselect呼び出しを保存するのではなく、デバッグを容易にするためです。 （もちろん、これが実行不可能であることが判明した場合は、スキームを変更するのは簡単です。）受信をブロックすることで論理サーバの厳密なタイミングを保証できるので、2つのサーバで通信を記録するとき、後で使用できます。デバッグや実行の方法にかかわらず、ゲームロジックを完全に再作成するプロセスによって、論理サーバーの動作を完全に再現することができます。つまり、既知のパケットは0.1秒ごとに受け入れられてから処理されます。

そうすることで、ネットワーク層のコード量に対するロジックサーバーの必要性が大幅に減少し、ロジックをより集中的に構築することができます。