UDP广播/多播与单播行为（丢弃的数据包）-Java 学习之路

我有一个嵌入式设备（源），它通过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模式下运行 .

2 回答

1

这看起来像是众所周知的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接收器（如我的情况），数据包丢失是巨大的，并且完全不能接受音频 .

回复于 2024-05-02T15:30:30+08:00
9

组播没有ack数据包，因此没有丢失数据包的重传 . 这很有意义，因为有很多接收器并且它们不能同时响应（空气像同轴电缆以太网一样共享） . 如果他们都使用一些退避计划按顺序发送acks，那么它将占用你所有的带宽 .

具有分组丢失的UDP流是众所周知的挑战，并且通常使用某种类型的前向纠错来解决 . 最近，称为喷泉代码的类，例如Raptor-Q，显示出丢包问题的希望，特别是当同时存在几个不可靠的数据源时 . （例如：覆盖区域的多个wifi接入点）

回复于 2024-05-02T15:30:30+08:00

UDP广播/多播与单播行为（丢弃的数据包）

2 回答

相关问题