2

私は現在、bittorrentクライアントを書いています。私は自分のプログラムの段階に到達しており、複数のスレッドが自分のプログラムを改善するかどうか、そしていくつ必要になるかについて考え始める必要があります。

プログラムは一度に複数（およそ1〜5）のスレッドと接触する可能性があるため、トラッカーを処理するために1つのスレッドを割り当てると想定しますが、トラッカーによって割り当てられた間隔（約20）でのみそれらに接触する必要があります。分）なので、プログラムにあまり集中しません。

プログラムは、多数のピアと定期的に連絡を取り、ピアからファイルをダウンロードします。以下は、Bittorrent仕様Wikiからの抜粋です。

実装者注：30ピアでも十分ですが、公式クライアントバージョン3は、実際には、ピアが30未満の場合にのみアクティブに新しい接続を形成し、ピアが55の場合は接続を拒否します。この値はパフォーマンスにとって重要です。新しいピースのダウンロードが完了すると、HAVEメッセージ（以下を参照）をほとんどのアクティブなピアに送信する必要があります。その結果、ブロードキャストトラフィックのコストは、ピアの数に正比例して増加します。25を超えると、新しいピアがダウンロード速度を上げる可能性はほとんどありません。UI設計者は、これを変更するのが非常にまれであるため、これをあいまいで変更しにくいものにすることを強くお勧めします。

それは私がおよそ30人の仲間と連絡をとるべきであることを示唆しています。私のBittorrentクライアントに使用するのに適したスレッドモデルは何でしょうか？明らかに、各ピアと各トラッカーにスレッドを割り当てたくはありませんが、おそらくメインスレッド以上のものが必要になります。何を指示してるんですか？

4

2 に答える 2

3

ここではマルチスレッドの必要性はあまりありません。スレッドが多すぎるということは、スレッド間で多くのコミュニケーションを取り、全員が適切なタイミングで適切なことを実行していることを確認することも意味します。

ネットワーキングの場合、すべてを1つのスレッドに保持し、ノンブロッキングI/Oを使用して多重化するだけです。Unixシステムでは、これはselect / poll（またはepollなどのプラットフォーム固有の拡張機能）を使用したセットアップになります。Windowsでは、これは完了ポートになります。

これにディスクI/Oを追加することもできます。これにより、スレッド間の通信が簡単になります。

スレッドを個別のコンポーネントのコンテナーと見なす場合は、ディスクI/Oが別のスレッドに入る可能性があります。この場合、多重化はそれほど多くないため、ブロッキングI/Oを使用できます。

同様に、このようなシナリオでは、トラッカー処理はピア処理とは異なるコンポーネントであるため、別のスレッドに入る可能性があります。DHTについても同じです。

チェックサムチェックを別のスレッドにオフロードすることをお勧めします。これがどれほど複雑になるかはよくわかりませんが、CPUの使用量が多い場合は、I/Oから離れてもそれほど悪くはありません。

于 2012-07-22T12:08:36.770 に答える
1

質問にタグを付けたので[C++] C ++ 11のstd：threadをお勧めします。あなたがここで見つける素晴らしいチュートリアル（他の多くの中で）。

スレッド数について：30スレッドを問題なく使用して、何かすることがあるかどうかをチェックし、チェックの合間に妥当な時間スリープ状態にすることができます。残りはオペレーティングシステムが処理します。

于 2012-07-22T11:39:05.757 に答える