1

这是我遇到的一个非常奇怪的错误，它似乎是 WinRT 框架的限制。复制这个问题的代码会占用太多空间，所以我会尽可能地描述它。在我的应用程序中，UI 由一些静态 TextBlock、一个不确定的进度条、一个确定的进度条和一个每秒更新的状态 TextBlock 组成。

DatagramSocket当使用高速 (~30Mbps)下载 UDP 数据包时，网络层和应用层之间会发生明显的数据包丢失 (>60%)。我说它在应用层，因为在执行下载时运行数据包跟踪（例如netsh trace）会显示网络层正在接收的所有数据包，而应用层没有。

我只能假设 WinRT 框架无法跟上MessageReceived需要触发回调函数的速度。我还没有找到任何对 UDP 下载执行任何缓冲的方法。我发现接收 UDP 数据包的唯一方法是回调函数，它为每个单独的数据包触发。

同样，这种应用层数据包丢失发生在 30Mbps 左右的下载速度下。在 10Mbps 等较慢的速度下看不到它。

有没有其他人遇到过这个问题，或者有没有人知道在执行 UDP 下载时执行缓冲的方法？

4

1 回答 1

0

我已经在这个问题上工作了大约一周，并确定绝大多数数据包丢失是由于 UI 中存在进度条造成的。确定的进度条甚至不需要更新——它存在于 UI 中的事实足以导致严重的数据包丢失。如果没有进度条，我能够将数据包丢失减少到大约 2%（从 >60%）。

我还编写了一个瘦客户端来测试我的应用程序结构的其余部分没有负担的问题。瘦客户端仅使用硬编码值实现了 UDP 下载功能。即使完全没有 UI，我仍然在应用程序层看到 0.05% 的数据包丢失，所以这似乎确实是 WinRT 框架中的一个问题。当我向瘦客户端添加一个不确定的进度条时，数据包丢失率跃升至 >30%。

除非有人知道执行 UDP 下载的接收部分的另一种方法（MessageReceived回调除外），或者在 WinRT 框架中解决此问题之前，您似乎应该预计网络层和进行高速 UDP 下载时的应用层。此外，在执行 UDP 下载时不应使用进度条。

TL;DR：不要在 WinRT 中使用带有 UDP 下载的进度条，并且无论如何都希望在高速下会丢失一些数据包。

于 2012-11-09T15:43:44.987 回答