我目前正在开发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和＃34;手动＆＃34;之上实现我们自己的协议。片段和重建数据，但如果我们能找到一种方法将Windows上的数据包重建超时减少到500毫秒或更短，我们就可以避免这种情况。
我在谷歌和Stackoverflow上搜索了相关信息，但结果并不多，但没有一个有多大帮助。
因此问题：有没有办法通过Registry，Windows API或任何其他魔法减少Windows 10上的IPv4 UDP片段的重建超时，或者你有更好的建议吗？
答案 0 :(得分：0)
由于Windows 2000的硬编码，由于严格的RFC 2460兼容性，因此没有正式的方法来修改ip数据包重组超时。
目前唯一的可能性似乎是使用自Windows 7以来有限的原始套接字，并且不适用于每个套接字提供程序。这会使应用程序变得更加复杂。
我们将改变我们的软件协议，以便没有数据包＆gt; 1400字节正在发送。这迫使我们关注软件中的碎片，但是会阻止IP数据包碎片及其所有陷阱。也许这是处理此类问题的正确方法。