重用sock_fd用于UDP服务器响应与新sock_fd

Question

如果我有一个UDP服务器处理recvfrom的传入请求，处理进来的请求（可能很耗时），可能会发回一个响应，然后再次调用recvfrom，是吗最好用sockaddr* from中的信息创建一个新的sock_fd来发送响应或者使用服务器的sock_fd发送响应？

基本上，问题是我是否需要创建新的sock_fd的开销，或者我是否希望我的服务器能够处理请求而无需等待发送上一个请求的响应。

我无法根据应用程序的需求做出决定，因为这将在库中使用（因此我不知道是否需要响应，以及处理请求需要多长时间）。

我没有看到这不是一个真正的问题。在上面的粗体部分以及第一句的最后部分中清楚地提出了这个问题

Answer 1

无需创建新的sock_fd，因为创建的bind已经作为服务器进行了recvfrom调用。

此外，您必须确保客户端不等待阻止struct sockaddr中的响应。

如果大多数服务器无法给出正确的响应并且客户端根据错误代码执行重复请求或其他内容，则会发送一些错误代码，您可能需要以请求 - 响应方式设计协议。

如果处理是一个问题，那么你总是可以在队列中拥有+ recvfrom 的客户端，并通过发信号通知线程来唤醒处理，这样你的监听线程可以快速返回struct sockaddr，然后您可以在完成后将处理线索的响应发送到已保存的{{1}} 客户端。

Answer 2

  

我是否需要创建新的sock_fd

的开销

没有

  

或者我是否希望我的服务器能够处理请求而无需等待发送上一个请求的响应。

没有人必须等待通过UDP套接字发送消息。如果您愿意，您可以在单独的线程上处理每个传入的请求，如果需要，他们可以同时调用sendmsg()。

你绝对只想使用一个套接字。首先，这意味着回复将返回给客户端，并使用相同的源地址信息返回给客户端，这样可以减少整个过程的混乱。