【发布时间】：2018-09-30 03:12:35
【问题描述】：
我目前正在用 Visual C++ 开发一个图像采集应用程序，该应用程序从功能有限（即没有 UDP 校验和）的 UDP 硬件设备接收图像数据。设备与专用交换机有 GBit 连接，PC 使用专用 NIC 和 10GBit 连接到此交换机。
传输的图像数据由大小从 6528 到 19680 字节的数据包组成。这些数据包由硬件设备分段，并由 PC 上的网络堆栈重构。
有时一个数据包（称为数据包#4711）丢失，PC 端尝试重建它很长时间。在此时间跨度内，由于 16 位数据包 id 溢出，硬件设备会发送具有相同打包 id 的新数据包。现在，PC 收到（新）数据包 #4711 的新片段，并使用它来完成旧的、仍未组装的数据包并组装损坏的数据包。最重要的是，新的#4711 数据包的剩余片段被存储并与下一个#4711（将在几秒钟后收到）合并。所以系统运行的时间越长，就会有越多的数据包ID被泄露，直到根本无法通信。
我们无法在硬件设备上计算 UDP 校验和，因为它的功能有限。
我们不能使用 IPv6（它会提供更大的数据包 ID），因为不支持硬件设备。
我们将不得不在 UDP 之上实现我们自己的协议并“手动”分段并重建数据，但如果我们能找到一种方法将 Windows 上的数据包重建超时减少到 500 毫秒或更短，我们就可以避免这种情况。
我在 Google 和 Stackoverflow 上搜索了信息，但结果并不多，而且没有一个有太大帮助。
因此问题是：有没有办法通过注册表、Windows API 或任何其他魔法来减少 Windows 10 上 IPv4 UDP 片段的重建超时，或者您有更好的建议吗？
【问题讨论】：
-
一个 UDP message 是由您为套接字配置的 receive timeout 内的片段构建的（即，如果完整的消息没有到达，您将得到超时错误）。您可以将此超时配置为您希望的任何值。
-
我尝试了 500 毫秒超时，但我仍然收到由 20 秒旧片段构建的数据包。我相信至少在 Windows 下，RCVTIMEO 只配置了 recvfrom() 调用的最大阻塞时间。
标签： windows sockets networking udp ip-fragmentation