4

ゲートウェイにネットワークアプリケーションがあります。パケットを送受信します。ほとんどの場合、私のゲートウェイはルーターとして機能しますが、場合によっては、パケットを受信することもできます。

私が持っている必要があります:

  • メインスレッドは1つだけ
  • メインスレッド+正しいフローハンドラーに渡すことを担当するディスパッチスレッド
  • フローと同じ数のスレッド
  • 他の何か。

4

4 に答える 4

2

マルチスレッドを正しく行うことは簡単なことではありません。多くの場合、selectfriendsベースのソリューションを作成する方がはるかに簡単です。

于 2012-06-29T14:48:23.780 に答える
2

あなたのケースは、典型的な Unix サービス デーモンのように聞こえます。問題に対する一般的な解決策は、スレッドではなくフォークを使用することです。

アイデアは、プログラムがソケットをリッスンし、接続を待機することです。接続が到着するとすぐに分岐します。その後、子プロセスは接続の処理を続行します。親プロセス自体はループ内で継続し、着信接続を待ちます。

スレッド化に対する利点:

  • 非常にシンプルなプログラム設計
  • 並行性に問題はありません
  • Unix/Linux システムの確立された方法

短所:

  • 複数の接続が相互に作用すると、事態は複雑になります (ユースケースはそのようには聞こえません)。
  • Windows システムでのパフォーマンスの低下 (Unix システムではありません!)

多くのコード例をオンラインで見つけることができます。

于 2012-06-29T14:52:38.507 に答える
1

ネットワーク アプリケーションについてはよくわかりませんが、次のようなものだと思います。

  • リクエストに対して非同期に反応できる場合は、おそらく 1 つのスレッドのみを使用します (Node.JS のように)。非同期に反応できない場合、メインスレッドは常に他のアクションをブロックします。
  • リクエストに対して非同期に反応できない場合は、複数のスレッドを使用する必要があります。ただし、これはさまざまな方法で実現できます。リクエストごとにスレッドを作成するか、限られた数のスレッドを作成してリクエストに割り当てることができます。
于 2012-06-29T14:50:48.677 に答える
0

私の個人的な好みは、接続ごとに 1 つのメイン スレッドと 1 つのワーカー スレッドを使用することです。キャップは一切ありません。サーバーは HTTP サーバーのようにステートレスになると想定しています。

ステートフル サーバーの場合、スレッド数を制御する何らかの方法を考え出す必要があります。

于 2014-04-29T00:27:46.153 に答える