我有一个很困惑的问题。
我正在使用一个大型 C++ 库来处理 Windows XP/7 上 UDP 上的一些专有协议(protocol)。它在整个程序运行过程中监听一个端口，并等待来自远距离对等方的连接。
大多数时候，这很有效。但是，由于我遇到的一些问题，我决定在调用 WSARecvFrom 之后直接添加一个简单的调试打印(库中使用的 win32 函数从我感兴趣的套接字接收数据报，并告诉他们来自哪个 IP 和端口)。
奇怪的是，在某些情况下，我发现数据包在操作系统级别被丢弃(即我在 Wireshark 中看到它们，它们具有正确的 dst 端口，所有校验和都是正确的 - 但它们从未出现在我植入代码的调试打印中)。
现在，我完全了解“UDP 不保证交付”这一事实(人们倾向于经常提及)——但这无关紧要，因为数据包已收到通过机器 - 我在 Wireshark 中看到它们。
此外，我熟悉操作系统缓冲区和填满的可能性，但奇怪的部分来了......
我做了一些研究，试图找出哪些数据包被丢弃了。我发现，所有丢弃的数据包都有两个共同点(虽然一些，但绝对不是大多数，不是 也放弃了分享这些):
- 它们很小。协议(protocol)中的许多数据包都很大，接近 MTU - 但所有丢弃的数据包都小于 100 字节(总字节)。
- 它们总是以下两者之一:SYN 等价物(即对等点发送给我们的第一个数据包以启动通信)或 FIN 等价物(即对等点不再有兴趣交谈时发送的数据包给我们)。
这两种特性中的任何一种都会影响操作系统缓冲区，并导致数据包被随机(或者更有趣的是 - 选择性地)丢弃吗？
任何关于这个奇怪问题的线索都将不胜感激。
非常感谢。
编辑(24/10/12):
我想我可能错过了一个重要的细节。似乎在到达之前丢弃的数据包有其他共同点:它们(我开始相信，只有它们)由"new"对等方发送到服务器，即它 的对等方strong>之前没有尝试联系过。
例如，如果一个 syn-equivalent 数据包来自一个我们以前从未见过的对等点*，它不会被 WSARecvFrom 看到。然而，如果我们已经向那个对等方我们自己发送了一个 syn-equivalent 数据包(即使它当时没有回复)，现在它向我们发送了一个 syn-等效，我们将看到它。
(*) 我不确定这是我们未见过的 peer(即 ip:port)还是我们未见过的 port之前。
这有帮助吗？
这是我从未听说过的某种 WinSock 选项吗？ (正如我上面所说，代码不是我的，所以它可能使用了我不知道的套接字选项)
再次感谢!
最佳答案
操作系统有一个固定大小的缓冲区，用于存放已到达您的套接字但尚未被您读取的数据。当此缓冲区耗尽时，它将开始丢弃数据。调试日志记录可能会延迟您从套接字中提取数据的速率，从而增加溢出的可能性，从而加剧这种情况。
如果这是问题所在，您至少可以通过请求更大的接收缓冲区来减少它的实例。
您可以使用
检查套接字接收缓冲区的大小int recvBufSize;
int err = getsockopt(socket, SOL_SOCKET, SO_RCVBUF,
(char*)&recvBufSize, sizeof(recvBufSize));
您可以使用
将其设置为更大的尺寸int recvBufSize = /* usage specific size */;
int err = setsockopt(socket, SOL_SOCKET, SO_RCVBUF,
(const char*)&recvBufSize, sizeof(recvBufSize));
如果您仍然看到操作系统正在接收数据但未传送到您的套接字客户端，您可以考虑使用不同的日志记录方法。例如
- 记录到 RAM 缓冲区并仅偶尔打印(以您认为最有效的大小)
- 从低优先级线程记录日志，要么接受此内存需求将不可预测，要么添加代码以在日志缓冲区已满时丢弃数据
关于windows - UDP 数据包，被 Wireshark 看到，被(甚至没有到达)WSARecvFrom 丢弃，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12834501/