QTcpServer と QTcpSocket の上に実装された FTP サーバーがあります。
スレッドが 1 つしかない場合でも、シグナルとスロットのメカニズムを利用して、複数の TCP 接続を同時にサポートします。私のコードはできるだけ早くイベント ループに戻り、ブロックせず (待機関数なし)、ネストされたイベント ループをどこにも使用しません。そうすれば、Win3.1 アプリケーションが持っていたように、私はすでに協調マルチタスキングを持っています。
しかし、他の多くの FTP サーバーはマルチスレッド化されています。各 TCP 接続を処理するために個別のスレッドを使用すると、パフォーマンス、特にレイテンシが向上するかどうか疑問に思っています。
一方では、新しい接続ごとに新しいスレッドを開始する必要があるため、スレッドはレイテンシーを増加させますが、他方では、私の協調的マルチタスクでは、他の TCP 接続は、readyRead()/bytesWritten()シグナルの前にメインループに戻るまで待機する必要があります。扱うことができます。
現在のシステムでは、ファイルI / O時間を無視すると、1つのプロセッサは、実行するのに役立つことがあれば常に何か有用なことを実行し、実行するのに役立つことがない場合はすぐに使用できる状態で待機します。これがシングルプロセッサ（シングルコア）システムの場合、スループットが最大化されます。これは多くの場合、非常に優れた設計です。特に、通常、パケットごとに人間が待機することのないFTPサーバーの場合はそうです。
また、平均レイテンシーを最小限に抑えました（シングルプロセッサーシステムの場合）。あなたが持っていないのは、一貫したレイテンシーです。システムのパフォーマンスを測定すると、多くのジッターが発生する可能性があります。これは、パケットの処理にかかる時間に大きなばらつきがあります。これもFTPであり、リアルタイムのプロセス制御や人間との対話ではないため、ジッターは問題にならない可能性があります。
ただし、システムで使用可能なプロセッサがおそらく複数あり、I/O時間と処理時間が重複する可能性があることを考慮してください。
マルチプロセッサ（コア）システムを最大限に活用するには、ある程度の同時実行性が必要です。
これは通常、複数のスレッドを使用することを意味しますが、非同期（非ブロッキング）ファイルの読み取りと書き込みを介して同時実行を実現できる場合があります。
ただし、プログラムに複数のスレッドを追加すると、巨大なワームの可能性が広がります。
MTルートを選択する場合は、スレッド対応のI/Oライブラリに依存することを検討することをお勧めします。QTはあなたにそれを提供するかもしれません（私にはわかりません）。そうでない場合は、boost :: asio（または古いがまだ固溶体の場合はACE）を見てください。このようなライブラリのMT機能を使用するには、学習時間にかなりの投資が必要であることがわかります。ただし、マルチスレッドを「手動で」追加して正しく実行する時間はさらに悪くなります。
したがって、未使用のプロセッササイクルやジッターが心配な場合を除いて、既存のソリューションをそのまま使用してください。その場合は、QTのマルチスレッドサポートまたはboost::asioの学習を開始してください。
新しい接続ごとに新しいスレッドを開始する必要がありますか? リクエストが到着したときにリクエストに応じて動作するスレッドのプールだけではありませんか。これにより、レイテンシがいくらか減少するはずです。一般に、マルチスレッドの FTP サーバーは、シングルスレッドの FTP サーバーよりも応答性が高いはずです。イベントベースの FTP サーバーを持つことは可能ですか?