c++ - 如何从一个 UDP 套接字处理多个客户端？

Question

我现在正在处理一个问题，我不知道正确/最佳的解决方案。

考虑以下示例:

假设你有一个 Socket，像这样:

SOCKET s = socket(AF_INET,SOCK_DGRAM,IPPROTO_UDP);

在这个套接字上，我将其称为“ServerSocket”，有许多来自许多不同 ip+port(客户端)的传入的 udp 数据包。

由于在这个套接字上的 recvfrom() 中创建多个线程阻塞似乎不是一个好主意，我想到(也许)一个专用线程，它只是阻塞在 recvfrom() 上，将那些 ip+port+ msg 组合成某种“全局队列”(std::queue，由互斥锁保护)。

到目前为止，一切顺利。

我了解 IOCP，关于它的第一个问题是:针对此类问题/在一个套接字上使用 IOCP 是否有意义？我遇到的问题是，即使 UDP 数据包(我们都知道协议(protocol)本身不能保证)以正确的顺序进入套接字，也会存在线程顺序的问题。例如，如果我将 IOCP 与四个线程和四个未完成的重叠 wsarecvfrom() 一起使用，则包 1 2 3 4 可能会被线程调度程序重新排序，例如到 3 4 1 2。如果只使用一个未完成的 wsarecvfrom()，一切都按预期工作，因为一次只有一个线程处理 wsarecvfrom()，将该消息放入客户端队列并发布下一个重叠的 wsarecvfrom()。

此外，我想在阻塞模式下模拟 recvmsg() 和 sendmsg() 等函数，但这里的问题是，例如如果您有数千个客户端，则无法打开 1000 个线程，这些线程都有其专用的 recvmsg() 阻塞，例如客户端消息队列的条件变量。这也是一个问题，因为客户端可能会被删除，通过接收一个包，其中可能包含类似“CLOSE_CONNECTION”的内容，以模拟 closesocket()，就像 TCP 使用它一样。

我需要使用UDP，因为用户发送的数据是时间紧迫的，但不一定是可靠的；只有状态消息应该尽可能可靠，例如“CONNECT_REQUEST”，如果客户端“连接”(就像 tcp 那样，我们都知道，udp 不这样做，所以如果需要的话，我们必须自己写)。也需要按顺序发送客户端消息。

总而言之，应给出以下标准:- 需要客户端消息部分的有序消息- 客户端消息的可靠性不是必需的(仅对于状态包，如“ACK_PACKAGE”等......我们谈论的是最新消息>比接收消息的可靠性更重要)- 必须管理许多客户端，并且必须检测诸如断开连接(软/硬，例如客户端是否插入网络电缆或其他...)之类的事情(计时器的线程池？)

所以我的最后一个问题是:实现这样的目标的最佳方法是什么？使用 TCP 会更容易，因为一个 IOCP 线程可以监听一个 accept()ed TCP 套接字，因此不会有线程重新排序问题。对于一个 UDP 套接字，您不能那样做，所以也许必须有类似重叠请求的东西，但只是针对一个……好吧，“自定义”事件。

Answer 1

您是正确的，基于 IOCP 的服务器使用多个线程来为 IOCP 提供服务可以而且将需要显式排序以确保以正确的顺序处理多个并发读取的结果。这同样适用于 TCP 连接(参见 here)。

我通常使用 TCP 处理此问题的方法是为每个连接设置一个计数器，该计数器是作为元数据添加到用于该连接上的 recv 的每个缓冲区的值。然后，您只需确保按顺序处理缓冲区，因为发出的读取顺序是 IOCP 读取完成的顺序(这只是导致问题的 IOCP 读取的多个线程的调度)。

如果您有一个所有对等方都发送到的“众所周知的端口”，则您不能对 UDP 采用这种方法，因为您的序列号没有与之关联的“连接”。

此外，UDP 的一个复杂问题是您和您的对等方之间的路由器可能会设法在任何数据报到达您之前重新排序或复制它们。这不太可能，但如果你不考虑它，那么当你向重要人物演示它时，这肯定是发生的第一件事......

这导致了这样一个事实，即要对 UDP 进行排序，您需要在数据报的数据部分中使用一个序列号。然后，您会遇到 UDP 数据报可能丢失的问题，因此序列号对于确保按顺序处理所有入站数据的用处不大，而仅在确保您永远不会乱序处理任何数据报方面有用。也就是说，如果你的数据报中有一个序列号，你所能做的就是确保你永远不会处理来自该对等点的数据报，其序列号小于或等于你上次处理的序列号(实际上你需要丢弃可能有效的数据)。

这实际上与具有单个对等点的单线程系统所遇到的问题相同，尽管在重要的演示之前，当您获得恰好导致的网络配置时，您可能会在不严格的情况下逃脱在重复的数据报或乱序的数据报中(都非常合法)。

为了提高系统的可靠性，您需要在 UDP 之上构建更多协议(protocol)。也许看看this question及其答案。然后注意不要构建比 TCP 更慢、更差、对其他网络用户更不礼貌的东西......