9

I have an embedded device (source) which is sending out a stream of (audio) data in chunks of 20 ms (= about 330 bytes) by means of a UDP packets. The network volume is thus fairly low at about 16kBps (practically somewhat more due to UDP/IP overhead). The device is running the lwIP stack (v1.3.2) and connects to a WiFi network using a WiFi solution from H&D Wireless (HDG104, WiFi G-mode). The destination (sink) is a Windows Vista PC which is also connected to the WiFi network using a USB WiFi dongle (WiFi G-mode). A program is running on the PC which allows me to monitor the amount of dropped packets. I am also running Wireshark to analyze the network traffic directly. No other clients are actively sending data over the network at this point.

When I send the data using broadcast or multicast many packets are dropped, sometimes upto 15%. However, when I switch to using UDP unicast, the amount of packets dropped is negligible (< 2%).

Using UDP I expect packets to be dropped (which is OK in my Audio application), but why do I see such a big difference in performance between Broadcast/Multicast and unicast?

My router is a WRT54GS (FW v7.50.2) and the PC (sink) is using a trendnet TEW-648UB network adapter, running in WiFi G-mode.

4

2 回答 2

9

这看起来像是一个众所周知的 WiFi 问题：

引自http://www.wi-fiplanet.com/tutorials/article.php/3433451

802.11 (Wi-Fi) 标准将多播支持指定为异步服务的一部分。802.11 客户端站，例如无线膝上型电脑或 PDA（不是接入点），通过在仅指向接入点的 802.11 单播数据帧中发送多播数据包来开始多播传送。如果在数据帧中没有发现错误，接入点会以 802.11 确认帧向源站发送响应。

如果发送帧的客户端没有收到确认，则客户端将重新发送帧。对于多播，从无线客户端到接入点的数据路径的一部分包括传输错误恢复。在使用单播数据帧传输时，802.11 协议可确保基础设施和 ad hoc 配置中的站点之间的可靠性。

从客户端接收到单播数据帧后，接入点将数据（发起客户端想要多播的）作为多播帧传输，其中包含一个组地址作为预期接收者的目的地。每个目的站都可以接收到该帧；但是，他们不回应确认。结果，多播不能确保完整、可靠的数据流。

多播缺少确认意味着您的应用程序发送的某些数据可能无法到达所有目的地，并且没有成功接收的迹象。不过，这对于某些应用程序来说可能没问题，尤其是那些可以在数据中存在间隙的应用程序。例如，来自控制阀监视器的连续遥测数据流可能会不时错过状态更新。

本文有更多信息： http ://hal.archives-ouvertes.fr/docs/00/08/44/57/PDF/RR-5947.pdf

多播实现（在 WiFi MAC 层）的一个非常有趣的副作用是，只要您的接收器是有线的，您就不会遇到任何问题（由于接收器端的确认，这实际上是一个单播连接） . 然而，使用 WiFi 接收器（如我的情况），数据包丢失是巨大的，对于音频来说是完全不可接受的。

于 2013-07-09T18:07:24.447 回答
1

组播没有确认数据包，因此不会重传丢失的数据包。这很有意义，因为有很多接收器，而且它们不能同时回复（空气像同轴电缆以太网一样共享）。如果他们都使用某种退避方案按顺序发送确认，它会吃掉你所有的带宽。

丢包的 UDP 流是一个众所周知的挑战，通常使用某种类型的前向纠错来解决。最近，一个被称为喷泉码的类，例如 Raptor-Q，显示了丢包问题的前景，特别是当同时有多个不可靠的数据源时。（例如：覆盖一个区域的多个 wifi 接入点）

于 2014-03-08T13:55:17.010 回答