クライアントがサーバに何らかの番号を送り、その応答、他の乱数を待つプログラムを書く必要があります。それは無限に送信され、番号を送信して応答を待つなどの処理を行います。サーバ内の多くのソケットを効率的に処理する
スレッドを作成せずに効率的に行うにはどうすればよいですか（ソケットを作成する）作成されたすべてのソケットに）？
リクエストとレスポンスごとにソケットを開いたり閉じたりする方が良いですか？
どのソケットが正しいソケットであるかわからないときにソケットを使って回答を送信する方法はありますか？しかし、すべてのソケットが同じクライアントコンピュータから始まり、クライアントのポートソースを知っています。 （私はソケット配列の作成について考えました）
どのように効率的に（作成されたすべてのソケットにスレッドを作成することなく）行うことができますか？
ソケットごとの新しいスレッドが非効率的であるという証拠がないと仮定しています。そうではありません。
要求と応答ごとにソケットを開いたり閉じたりする方が良いですか？
いいえHTTPの履歴を見てください。 1.0と1.1の間の大きな変化は、サーバー側のアーキテクチャに関係なく実行された永続的な接続の導入でした。
私はそのような状況はおそらく発生する可能性がどのように理解していない右のソケット
である1かわからないとき、ソケット上で解答を送信する方法はあります。答えは、特定のソケットに関連する特定のセッションのコンテキストでのみ意味があります。あなたがその情報を保持していない場合は、あなたがする必要があります。それは単なるデータ構造の問題です。
が、私はすべてのソケットが同じクライアントコンピュータから起動し、送信元ポートにあなたを思い出すことができる場合、私は
（私はソケットの配列を作りについて考えた）クライアントのポートソースを知っていることを知っていますソケット自体を覚えることができます。ここでも、これは単なるデータ構造の問題です。また、すべての接続が同じクライアントからのものであるという仮定/制約は必要ありません。また、そのクライアントがマルチスレッドでない限り、クライアントからの複数の接続はまったく必要ありません。
私は同じコンピュータから複数のクライアントプログラムを実行することを意味しました –
ありがとう –
スレッドを使用できるようになると、スレッドを再利用するために境界キューを持つブローカーを使用できます – Palcente
将来について心配する前に、まずソケットあたりの標準的なスレッド方法を試してみてください。ソケットに関する知識がほとんどない場合、パフォーマンスの問題に集中するのは良い考えではありません。 – Kayaman