2

I'm experimenting with WIFI multicasting and broadcasting using Raspberry PIs as clients. If I subnet-broadcast or multicast over the WIFI then I lose a lot of packets. If I 'broadcast' to the specific IP of the receiver then I don't lose any packets. I have only the 1 receiver/client connected to my WIFI AP. I'm using QT framework's QUDPSocket::writeDatagram. So I just have to set the IP there and broadcast/subnet-broadcast/multicast is inherently selected. I have verified the appropriate MAC addresses are set using Wireshark and everything seems correct. I can't understand why I'm getting such a huge difference in performance. It's all UDP and there's only a single WIFI client. Any ideas please?

Edit in response to Sam Mason: QUDPSocket::writeDatagram takes an IP address. That IP address dictates whether you are unicasting, multicasting, broadcasting, or sub-net-broadcasting. I'm looping on this call to achieve a fixed tx speed of 1.5Mbps. (this is slow compared to what I should be able to push across my WIFI network so I'm not asking for a lot). My question really is why should unicast drop zero packets whilst all other methods drops lots of packets. I'm aware of the 'lowest common denominator' aspect of non-unicast but I only have 1 client connected, so...what does that mean?). I'm really after a nuts-and-bolts explanation of the real difference between UDP unicast and UDP-broadcast-with-single-client-connected.

kingrolo
  • 2,857
  • 2
  • 16
  • 11
  • Another difference is that the broadcast goes to every host in the subnet, interrupting the kernel all the way up to the UDP layer. – user207421 Nov 03 '19 at 09:28
  • True fact about broadcasting but not relevant. I’m only interested in the route from the server to my only WiFi client. Does a broadcast interrupt the kernel more than a Unicast? – kingrolo Nov 03 '19 at 09:58
  • It interrupts *other*, non listening kernels, more than a unicast or a multicast. – user207421 Sep 09 '21 at 01:00

2 Answers2

3

The short answer is: You are seeing artifacts of implementation details of your specific WLAN router. Other routers may or may not behave differently.

Details:

WLAN uses two general modes of communication on the link layer: Individually addressed or group addressed.

For 1:1 communication it uses individually addressed communication and this is made robust by acknowledges and retransmissions on the link layer. This is used for unicast UDP and for TCP etc.

For one to many communication it uses group addresses frames and there is no protection against packet loss at all on the link layer. In addition, in this mode the router may fall back to the slowest WLAN transfer rate (1MBits/s) to make sure every STA can receive it.

Now the WLAN router has some freedom which mode it uses for which IP packet:

Any packet (unicast/multicast/broadcast) from sender to WLAN router: Individually addressed. This is always a 1:1 relationship (one sender to one router).

UDP unicast and TCP etc: It uses individually addressed frames to send to the target STA. No packet loss. High speed.

UDP multicast: Some WLAN routers (actually this is quite common) are smart and still use individually addressed frames when only one client has registered to receive this multicast group via IGMP. When multiple STAs want to receive the multicast frames it will most likely use group addresses (with visible packet loss). The router has the freedom to choose the data rate. Usually it will use a high data rate, not the 1 MBs fallback.

UDP broadcast: Most WLAN routers will blindly use group addressed (with visible packet loss) and will use the 1MB/s fallback data rate as the lowest common denominator.

UDP mutlicast and UDP broadcast over WLAN behaves very different from UDP multicast and UDP broadcast over ethernet. You have to expect lots of artifacts, packet loss, reordered packets, very slow data rate.

The above explains why you see lots of lost packets when firing 1.5 MB/s broadcasts over the slow 1MB/s group address link using the 1 MB/s fallback data rate.

ahcox
  • 9,349
  • 5
  • 33
  • 38
Johannes Overmann
  • 4,914
  • 22
  • 38
  • The answer may well be in your initial statement that UDP unicast still uses acks and resends at the link layer. I didn't know this. Wireless is unpredictable and this could/would make all the difference. I have tried 3 different routers and played with the IGMP option and limiting the broadcast rate, but I still get more lost packets than I would have expected. UDP unicast with acks+resends may be obfuscating a fundamentally unreliable WIFI connection. Thanks for the great explaination. – kingrolo Nov 04 '19 at 09:38
  • Yes, exactly: I was also quite confused when I stumbled over a completely reliable multicast UDP WLAN connection. But you can see evidence of this in a WLAN packet trace (when you do not see any group address frames and only individuall address frames for a multicast stream). The confusing bit is that the IGMP implementations in the STAs often have long timeouts of 5 minutes or so and thus prevent you from reasoning in a logical way. Quite horrible for a systematic analysis. You always have to power everything off to be sure. :-) – Johannes Overmann Nov 04 '19 at 15:28
0

assuming I'm interpreting your question correctly, then it's because unicast runs much faster than broadcast/multicast. see https://superuser.com/a/695967 for more information, and the linked question For UDP broadcast gurus: Problems achieving high-bandwidth audio UDP broadcast over WiFi (802.11N and 802.11G) is also relevant

to quote a relevant part:

Any kind of multicast/broadcast over Wi-Fi is going to be slow because Wi-Fi requires multicasts and broadcasts to be sent at a kind of "lowest common denominator" transmission speed.

would be great if you included a few relevant lines of code, as your verbiage is somewhat ambiguous. e.g. what do you mean by "'broadcast' to the specific IP of the receiver"? I'm assuming you just mean send!

Sam Mason
  • 15,216
  • 1
  • 41
  • 60