0

我目前正在用 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 毫秒或更短，我们就可以避免这种情况。

我搜索了谷歌和 Stackoverflow 的信息，但结果并不多，而且没有一个有太大帮助。

因此，问题是：有没有办法通过注册表、Windows API 或任何其他魔法来减少 Windows 10 上 IPv4 UDP 片段的重建超时，或者您有更好的建议吗？

4

1 回答 1

0

由于 Windows 2000 对其进行了硬编码，因此由于严格的 RFC 2460 兼容性，没有官方方法可以修改 ip 数据包重组超时。

详细信息可以在这里阅读： https ://blogs.technet.microsoft.com/nettracer/2010/06/03/why-doesnt-ipreassemblytimeout-registry-key-take-effect-on-windows-2000-or-later-系统/

目前唯一的可能性似乎是使用自 Windows 7 以来受到限制且并非每个套接字提供程序都可用的原始套接字。这将使应用程序更加复杂。

我们将更改我们的软件协议，以便根本不发送 > 1400 字节的数据包。这迫使我们关心软件中的碎片，但防止 IP 数据包碎片及其所有陷阱。也许这是处理此类问题的正确方法。

于 2018-04-23T05:58:51.600 回答