recvfromで受信リクエストを処理し、受信したリクエストを処理し（おそらく時間がかかる）、おそらく応答を返し、次に再度呼び出すUDPサーバーがある場合、送信recvfromする情報を含む新しいsock_fdを作成することをお勧めしsockaddr* fromますサーバーの sock_fd を使用して応答を送信しますか?
基本的に、問題は、新しい sock_fd を作成する必要があるというオーバーヘッドが必要なのか、それともサーバーが前のリクエストへの応答を送信するのを待たずにリクエストを処理できるようにしたいのかということです。
これはライブラリで使用されるため、アプリケーションのニーズに基づいて決定することはできません (したがって、応答が必要かどうか、および要求の処理にかかる時間がわかりません)。
これが本当の質問ではないことがわかりません。上記の太字のセクションと、最初の文の最後の部分で、質問が明確にされています。
sock_fd作成されたものはすでにbindサーバーとして呼び出しを行っているため、新しいものを作成する必要はありません。
また、クライアントがブロッキングで応答を待っていないことを確認する必要がありますrecvfrom。
ほとんどのサーバーは、適切な応答を返すことができず、クライアントがそのエラー コードに応じて繰り返し要求または何かを行う場合、いくつかのエラー コードを送信します。要求と応答の方法でプロトコルを設計する必要がある場合があります。
処理に問題がある場合は、常にstruct sockaddr クライアントのデータをキューに入れておき、スレッドにウェイクアップを通知することで処理を遅らせることができます。そうすることで、リッスンしているスレッドが高速に戻りrecvfrom、処理からの応答を送信できます。完了したら、保存されたstruct sockaddr クライアントへのスレッド。
新しいsock_fdを作成する必要があるというオーバーヘッドが必要ですか
いいえ。
または、前のリクエストに応答を送信するのを待たずに、サーバーがリクエストを処理できるようにしたいですか。
UDPソケットを介してメッセージを送信するのを待つ必要はありません。必要に応じて、すべての着信要求を個別のスレッドで処理できsendmsg()、必要に応じてすべて同時に呼び出すことができます。
あなたは間違いなく1つのソケットだけを使いたいです。一つには、返信が送信先と同じ送信元アドレス情報を使用してクライアントに返されることを意味します。これにより、全体的な混乱が少なくなります。