UDP广播/组播与单播行为(丢包)

Question

我有一个嵌入式设备(源)，它通过UDP数据包以20毫秒(约330字节)的块大小发送(音频)数据流。因此，网络容量相当低，约为16kBps(实际上由于UDP/IP开销而有所增加)。该设备正在运行lwIP堆栈(v1.3.2)，并使用H＆D Wireless的WiFi解决方案(HDG104，WiFi G模式)连接到WiFi网络。目的地(接收器)是Windows Vista PC，它也使用USB WiFi加密狗(WiFi G模式)连接到WiFi网络。 PC上正在运行一个程序，该程序可让我监视丢失的数据包的数量。我也正在运行Wireshark来直接分析网络流量。此时，没有其他客户端正在通过网络主动发送数据。

当我使用广播或多播发送数据时，许多数据包被丢弃，有时高达15％。但是，当我切换为使用UDP单播时，丢弃的数据包数量可以忽略不计(<2％)。

我希望使用UDP丢弃数据包(在音频应用程序中可以)，但是为什么在广播/多播和单播之间看到如此大的性能差异？

我的路由器是WRT54GS(FW v7.50.2)，而PC(接收器)使用的是Trendnet TEW-648UB网络适配器，该适配器以WiFi G模式运行。

Answer 1

看来这是一个众所周知的WiFi问题:
引用自http://www.wi-fiplanet.com/tutorials/article.php/3433451

The 802.11 (Wi-Fi) standards specify support for multicasting as part of asynchronous services. An 802.11 client station, such as a wireless laptop or PDA (not an access point), begins a multicast delivery by sending multicast packets in 802.11 unicast data frames directed to only the access point. The access point responds with an 802.11 acknowledgement frame sent to the source station if no errors are found in the data frame.

If the client sending the frame doesnt receive an acknowledgement, then the client will retransmit the frame. With multicasting, the leg of the data path from the wireless client to the access point includes transmission error recovery. The 802.11 protocols ensure reliability between stations in both infrastructure and ad hoc configurations when using unicast data frame transmissions.

After receiving the unicast data frame from the client, the access point transmits the data (that the originating client wants to multicast) as a multicast frame, which contains a group address as the destination for the intended recipients. Each of the destination stations can receive the frame; however, they do not respond with acknowledgements. As a result, multicasting doesnt ensure a complete, reliable flow of data.

The lack of acknowledgments with multicasting means that some of the data your application is sending may not make it to all of the destinations, and theres no indication of a successful reception. This may be okay, though, for some applications, especially ones where its okay to have gaps in data. For instance, the continual streaming of telemetry from a control valve monitor can likely miss status updates from time-to-time.

本文具有更多信息:
http://hal.archives-ouvertes.fr/docs/00/08/44/57/PDF/RR-5947.pdf
多播实现(在WiFi MAC层)的一个非常有趣的副作用是，只要您的接收器是有线的，您就不会遇到任何问题(由于接收器端的确认，这实际上是单播连接)。 。但是，对于WiFi接收器(以我为例)，丢包是巨大的，对于音频来说是完全不能接受的。