0

アプリケーション レベルのプロトコルが UDP 経由で実装されているとします。クライアントのタイムアウトが必要なため、サーバーは通信する各クライアントの状態を保持する必要があります。

また、使用されていると仮定しますselect。

  1. マルチスレッドサーバーを実装するのは常に最善ですか? サーバーのタイムアウトが発生する場合、リンクリストも同じことを行うと思いますtime=Earliest Timeout of a client- CurrentTime。リンクリストは、新しいスレッドを作成するオーバーヘッドを回避しながら、クライアントの状態を保持するのと同じ機能を持ちます (ただし、サーバーがクライアント固有のタイムアウトを維持するためにいくらか複雑になります)。

  2. マルチスレッドが選択された場合、それ以降は、新しいクライアントに対して新しいソケットを呼び出すのが最善ですか? これにより、システム リソースのオーバーヘッドが発生します。しかし、デフォルトのサーバーソケット（bindサーバーのウェルノウンポートを使用）は、バッファーを取得したため、同じことを行うと思います（まあ、スケーラブルな数のクライアントには十分な長さではないかもしれません..）

ありがとう！

4

4 に答える 4

2

私の経験では、恐ろしい同期の問題が潜んでいて、いくつかのイベントが適切な順序で発生してアプリケーションが爆発するのを待っているときに、スレッドを使用すると、コードを論理的かつクリーンに見せることが非常に簡単になります。スレッド化は非常に便利なツールです。アプリケーションが CPU を最大限に活用できるようになるには、スレッドについて考える必要があります。スレッドの操作を学習することは、分散処理の活用を学習するための第一歩です (少なくとも、 そう思います）。

私の好みは、呼び出しをブロックするのではなく、非同期コールバックを使用してアプリケーションを作成し、コールバックの処理に使用するスレッドを明示的に指示することです。これには次の利点があります。

  • これにより、状態変数の相互作用がより制御しやすくなり、予測可能になります。つまり、スレッド化がより堅牢になります。
  • 正しく行えば、CPU が持つプロセッサの数を最大限に活用できます。
  • 特定の関数に与える優先度を直接制御できます。この関数の優先度が高い場合は、優先度の高いスレッドにディスパッチし、完了すると、優先度の低い呼び出し元に結果を返します。呼び出し元のスレッドでの継続。または別のスレッドに - それを制限する理由はありません。
  • 多くの場合、非スレッド環境への移植が可能です。ほとんどの人にとっては重要ではないかもしれませんが、私にとっては重要なこともあります。

于 2010-01-29T20:43:53.307 に答える
1

Aidan Cullyの回答にない新しいことを提案するつもりはありませんが、Apacheのマルチプロセッシングモジュールの背後にある理論を見てください：http ：//www.linuxquestions.org/linux/answers/Networking/ Multi_Processing_Module_in_Apache

基本的に、サーバーは複数のモジュールに分割され、スレッド/プロセスは接続を管理するために作成されます。必要性と構成オプションに応じて、Apacheの実装はわずかに異なる場合がありますが、Aidanの回答で説明されているバランスのように聞こえます。

于 2010-01-29T20:50:31.603 に答える
0

リンクされたリストはスケーリングされません。

サーバー側でリンクされたリストを使用してクライアントを 1 つずつチェックし、そのニーズに対処することは、5 ～ 10 クライアントの場合はすべてうまくいきます。しかし、100 になるとどうなるでしょうか。1000? 1 つのクライアント要求の処理に非常に長い時間がかかる場合はどうなりますか?

スレッドは、個々のクライアントの状態を維持する方法を提供するだけではありません。また、すべてのクライアントに同時に「サーバー リソースを分散」する方法も提供します。あたかも各クライアントが専用のサーバーを持っているかのように、キューは (ほとんど) ありません。クライアントが何かを要求し、サーバーに問い合わせると、サーバーが応答します。それは瞬時です。

さらに、リンク リスト アプローチでは、貴重なリソースを浪費する可能性があります。1 人を除くすべてのクライアントが何も望んでいない場合はどうなりますか? サーバーの注意を必要とするクライアントに遭遇するまで、100 を超えるクライアントを繰り返し循環させ、CPU サイクルを浪費するだけです。

于 2010-01-29T20:26:06.203 に答える
-1

マルチスレッドは、すでに代替手段を考え出しているため、必須ではありません。ケースごとに固有の要件と制約があるため、常にまたは決して絶対的なものを実際に使用することはできません。

はい、接続ごとに新しいスレッド/ソケットを追加すると、より多くのリソースが消費されます。必要な接続数を適切に定義する必要があるようです。次に、十分なリソースがあるかどうかを判断できます。

リソースの制約が問題にならない場合は、より単純なソリューションを選択します。機能の新しい本体 (リンクされたリストの提案) を作成するのではなく、既に持っているツール (つまり、スレッドとソケットを処理するための十分にテストされた関数) を使用する方が簡単ですか? コードのメンテナンスはどうですか？将来、別のプログラマーがこのプロジェクトに取り組む場合、既に使い慣れた標準のオペレーティング システム コールまたはリンク リストを使用した実装を理解するのは簡単でしょうか?

于 2010-01-29T20:17:13.133 に答える