1

これは私が遭遇した本当に奇妙なバグであり、WinRTフレームワークの制限のようです。この問題を再現するためのコードはスペースを取りすぎるので、できる限り説明します。私のアプリケーションでは、UIは、いくつかの静的TextBlock、不確定なプログレスバー、確定的なプログレスバー、および1秒ごとに更新されるステータスTextBlockで構成されています。

DatagramSocket高速（〜30Mbps）でUDPパケットをダウンロードする場合、ネットワーク層とアプリケーション層の間で大幅なパケット損失（> 60％）が発生します。ダウンロードの実行中にパケットトレース（netsh traceなど）を実行すると、ネットワーク層が受信しているすべてのパケットがアプリケーション層ではないことが明らかになるため、これはアプリケーション層にあると言えます。

MessageReceivedWinRTフレームワークは、コールバック関数を起動する必要がある速度に追いつくことができないと思います。UDPダウンロードで何らかのバッファリングを実行する手段が見つかりませんでした。UDPパケットを受信するために私が見つけた唯一の方法は、個々のパケットごとに起動されるコールバック関数です。

この場合も、このアプリケーション層のパケット損失は、約30Mbpsのダウンロード速度で発生します。10Mbpsのような低速では見られません。

他の誰かがこの問題に遭遇したことがありますか、またはUDPダウンロードを実行するときにバッファリングを実行する方法を知っている人はいますか？

4

1 に答える 1

0

私はこの問題に約 1 週間取り組んできましたが、パケット損失の大部分は 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 に答える