p2p ではなく、クライアント サーバー ベースのインスタント メッセージング アプリケーションがあるとします。実際のプロトコルは問題ではなく、重要なのはサーバー アーキテクチャです。上記のサーバーは、非ブロック ソケットを使用してシングルスレッドの非並列モードで動作するようにコーディングできます。これにより、定義により、読み書きなどの操作を効果的に即時 (または瞬時) に実行できます。ノンブロッキング ソケットのまさにこの機能により、サーバーのコアである種の選択/ポーリング機能を使用し、実際のソケットの読み取り/書き込み操作でほとんど時間を無駄にすることなく、このすべての情報の処理に時間を費やすことができます。 . 私が理解している限り、適切にコーディングされていれば、これは非常に高速になる可能性があります。しかし、2 番目のアプローチがあります。それは積極的にマルチスレッド化し、新しいスレッドを作成することです (明らかに、ある種のスレッド プールを使用して、その操作そのものが、一部のプラットフォームや状況下では (非常に) 遅くなる可能性があるため)、メインのバックグラウンド スレッドが accept() などを処理している間、これらのスレッドを並行して動作させることができます。このアプローチがネット上のさまざまな場所で説明されているのを見たので、明らかに存在します。
問題は、非ブロッキング ソケット、即時の読み取り/書き込み操作、およびシンプルで簡単にコーディングできる設計がある場合、なぜ 2 番目のバリアントが存在するのでしょうか? 2 番目の設計、つまりスレッドで克服しようとしている問題は何ですか? 私の知る限り、これらは通常、遅くてブロックする可能性のある操作を回避するために使用されますが、そのような操作は存在しないようです!