这是我遇到的一个非常奇怪的错误，它似乎是WinRT框架的限制。复制此问题的代码将占用太多空间，因此我将尽可能地描述它。在我的应用程序中，UI由一些静态TextBlocks，一个不确定的进度条，一个确定的进度条和一个每秒更新的状态TextBlock组成。
当使用DatagramSocket以高速（~30Mbps）下载UDP分组时，在网络层和应用层之间发生显着的分组丢失（> 60％）。我说它在应用程序层中，因为在执行下载时运行数据包跟踪（例如netsh trace）会显示网络层正在接收的所有数据包，而不是应用程序层。
我只能假设WinRT框架无法跟上需要触发MessageReceived回调函数的速度。我还没有找到任何在UDP下载上执行任何缓冲的方法。我发现接收UDP数据包的唯一方法是回调函数，它会针对每个数据包触发。
同样，此应用层数据包丢失发生在大约30Mbps的下载速度。它没有像10Mbps那样以较慢的速度出现。
是否有其他人遇到此问题，或者有人知道在执行UDP下载时执行缓冲的方法吗？
答案 0 :(得分：0)
我已经在这个问题上工作了大约一个星期，并确定绝大多数数据包丢失是由于UI中存在进度条。确定的进度条甚至不需要更新 - 它存在于UI中的事实足以导致重大的数据包丢失。没有进度条，我能够将数据包丢失减少到大约2％（从> 60％）。
我还写了一个瘦客户端来测试那个没有我应用程序结构其余部分负担的问题。瘦客户端仅使用硬编码值实现UDP下载功能。即使完全没有UI，我仍然看到应用程序层中有0.05％的数据包丢失，所以这确实在WinRT框架中确实存在问题。当我向瘦客户端添加一个不确定的进度条时，数据包丢失率跃升至> 30％。
除非有人知道执行UDP下载的接收部分的另一种方法（MessageReceived回调除外），或者直到WinRT框架中解决了这个问题，否则你应该至少看到一些在进行高速UDP下载时，网络层和应用层之间的数据包丢失。此外，执行UDP下载时不应使用进度条。
TL; DR：不要在WinRT中使用带UDP下载的进度条，并且无论如何都要高速丢包。