安全に接続しているクライアントごとに新しいスレッドを作成するサーバーがあります。スレッドプールを使用する場合、これは、一度に有限数のクライアントを持つことを意味します。ただし、これは、すべてのクライアントのポートをリッスンできないことを意味します。
私の考えは、クライアントが接続にリンクされたIDを持つUDPパケットを送信して、スレッドを10〜60秒間ロックするのではなく、接続を再確立できるようにすることです（サーバーはSSLソケットをメモリに保持します）。それは問題を解決するための良い方法ですか？-セキュリティセキュリティの脆弱性は見当たりません。
サーバーはJavaであり、クライアントはC ++であり、質問に影響を与えることはありません。
あなたの質問は意味がありません。クライアントが再接続したい場合は、新しいソケットを開くだけです。UDPポートをリッスンするために、少なくとも1つの追加スレッドを配置し、次に...何をしますか？それがあなたの自主的な制約である場合、それはまだそのクライアントを処理するためにスレッドプールを使用する必要があります、さもなければ新しいスレッドを開始します、その場合あなたはそもそもスレッドプール制約を持っていなかったかもしれません。
ただし、これは、すべてのクライアントのポートをリッスンできないことを意味します。
いいえ、そうではありません。これは、スレッドプールがいっぱいのときに一部のクライアントが遅延サービスを取得し、バックログキューがいっぱいのときに接続障害が発生するクライアントが非常に少ないことを意味します。クライアントをリッスンする能力をまったく損なうことはありません。
あなたが持っている唯一のポートがTCP/443（HTTPS）だとしたらどうでしょうか？UDPがファイアウォールで保護されている場合はどうなりますか（非常に可能です）？つまり、この図にUDPを導入しないでください。
スレッドプールのシナリオでも、同じサーバーポートに接続した複数のクライアントの違いを知ることができます。
このための一般的な解決策は、一度に監視するソケットのセットを（1つのスレッドで）作成することです。C/ C ++では通常//を使用して実行select()さpoll()れepoll()、Javaではを使用できますjava.nio。
このように、クライアントがサーバーとしてあなたに何か言いたいことがある場合、selectループは即座にそれらのクライアントにサービスを提供しselect()、CPU使用率をほとんど（事実上0）消費しないに戻ります。
これは、Cでselectループを実行する方法の例であり、Javaで同様の例です。