1

KISS を維持しながら IO タイプのアーキテクチャを使用して実際に大量の接続を含める方法について、頭の中でいくつかのアイデアを回してきました。Web 上の例を見ると、ほとんどの場合、CONTAINING_RECORD を使用して二重/単一のリンク リストを使用しているようです。そして、IO サーバーの初心者 (とはいえ、日々改善しています) として、私も IO アーキテクチャにリンク リスト コンテナーを使用しています。

私の質問は、接続にシングル/ダブル リンク リストを使用する代わりに、大きな配列を作成して CONTAINING_RECORD を使用できないのはなぜですか? STLベクターは使えますか？それはうまくいくでしょうか？また、大規模なIOサーバーで最適に機能する他のタイプのコンテナは何ですか.

私はゲーム サーバーのサーバー アーキテクチャを (何度も改訂した後) 書き直している最中です。今回は正しい方向に進みたいと考えています。

お時間をいただき、ありがとうございます。

編集：現在、私のサーバーアーキテクチャは（一言で言えば）：

Main thread listening and accepting -> Pass over the socket into a container.
Worker threads(2-3) grab IO events for the container of sockets.
Worker threads Read/Write Data on that container.

メイン スレッドとワーカー スレッドはすべてリンク リストを使用します。私はこれから離れたいです。

4

2 に答える 2

1

あなたの「接続リスト」には、おそらく最後だけでなく、任意の位置からの削除があります。の場合std::vector、途中の要素を削除するのは O(N) 操作ですが、リンクされたリストの場合は O(1) になる可能性があります。(単一リンクのリストの場合、これは簡単ではなく、不便な API が必要になる場合があります)。

std::mapO(log N)要素の検索と削除の両方を提供するため、興味深い選択になる可能性があります。

于 2012-09-11T07:21:35.573 に答える
0

すべてのデータ構造と同様に、それはあなたがそれで何をしたいかに大きく依存します。

以前の仕事では、ほとんどの時間を、Windowsの化身でIO完了ポートを使用する非常にマルチスレッドのC ++サーバーで作業していました（Solarisバックエンドは/ dev / pollを使用しましたが、これはいくつかの重要事項でそれほど異なりません）。mapその1つは、ファイル記述子をキー値として使用して、STLの前にさかのぼる-のような構造に接続関連のデータ構造を格納しました。したがって、接続でイベントを取得するたびに、IOレイヤーから渡された記述子によって関連するデータ構造を検索できます。新しい接続は扱いやすく、辞書にエントリを追加するだけで、閉じた接続も非常に簡単にクリーンアップできます。

当然、これらの構造へのクロススレッドアクセスと操作の順序について注意する必要があります。IOは本質的に効果的であるため、操作の順序は非常に重要です。幸い、IOCPは、ソケットをCPに戻すまで、同じソケットの別のスレッドで別のイベントを発生させませんが、Solaris実装では、ファイル記述子をワーカースレッドにリンクする構造を維持して、処理のみを行う必要がありました。ソケットごとに一度に1つのイベントを厳密な順序で実行し、ソケットの構造を別のプロセッサに切り替える必要がないように、ソケットの後続のイベントを同じスレッドに挿入しようとしました。これは、キャッシュヒット率の障害になります。

ただし、基本的な要約として、適切に設計された辞書クラスは、この種のことには非常に役立つことがわかりました。

于 2012-09-11T07:07:18.710 に答える