When a host sends out a broadcast, how does it calculate the number of packets (same) that it needs to send out so that all the other hosts on the same LAN would receive it? For example, when a host boots up, it sends a DHCP broadcast to all the other hosts in the LAN. How can it determine the number of packets (same) to send?
Ok, double checked with wikipedia. You mention both "broadcast/multicast" in your title, but they're significantly different from each other.
There is no calculation for broadcast. The answer is, you don't know, or care, how many other hosts are out there. You send a single packet to the broadcast address, and it's the responsibility of every host listening to act on the packet that was sent. On a Class C subnet, such as a 192.168.x.x, the broadcast address is 192.168.x.255.
With multicast, the originating host still only needs to send out one packet, so again, no calculation of total packets is needed. From wikipedia:
Multicast uses network infrastructure efficiently by requiring the
source to send a packet only once, even if it needs to be delivered to
a large number of receivers. The nodes in the network take care of
replicating the packet to reach multiple receivers only when
necessary.
Related
I am trying to let two or more ESP32-S2s communicate from one to the others over udp. Since they possibly dont know each others ip i wanted to use multicast.
Sending MulticastPackets is working.(At least I can wireshark the Packets on my PC).
Recieving on the other esp doesnt work so far.
Im Broadcasting to 192.168.178.255:7777
The reciever uses the following code:
//Called once after Wifi is connected:
udp.beginMulticast(OAL_Broadcast, OALPort); // 192.168.178.255, 7777 as inputs
//Called periodically :
Serial.println(udp.parsePacket()); // In my case always returns 0
What am I missing?
A few things could be happening.
The multicast IP address range is between 224.0.0.0-239.255.255.255 and usually a device joins a multicast group on one of those. Also it might treat sending a multicast more loosely when it comes to the IP address but receiving one it must be within the range of multicast addresses due to how it routes that packet to a multicast group.
If one device is on another network device but still on the same network then it could be ttl related and each network device is treated as a hop. I have seen something like this happen before. You might be able to adjust that on the network device side or on the esp32 side.
I read RFC6577 and RFC8445 but I feel like there is a bit of a disconnect between how TURN can be used versus how ICE actually utilizes the relay candidates.
The TURN RFC describes the use of one single TURN server to ferry data between a client and a peer. The transport address on the TURN server accepts data flow from a client via TURN messages, whereas the relayed transport address accepts data flow from peer(s) via UDP. This sounds great - one TURN server and bidirectional data flow.
However in reading about ICE, I feel like this never happens. Both caller and callee independently allocate on potentially two TURN servers, and then send their respective relayed transport addresses to each other. More like an I can be reached via this relayed transport address sort of thing. Connectivity checks then occur and thus, two TURN servers end up being used here where data only flows in one direction through the relayed transport address of each participants allocated TURN server.
Is this true?
From the TURN RFC, it says the following:
The client can arrange for the server to relay packets to and from
certain other hosts (called peers) and can control aspects of how the
relaying is done. The client does this by obtaining an IP address and
port on the server, called the relayed transport address. When a peer
sends a packet to the relayed transport address, the server relays the
packet to the client. When the client sends a data packet to the
server, the server relays it to the appropriate peer using the relayed
transport address as the source.
However, I can't see a scenario whereby through ICE negotiations, data would ever flow through the transport address from the client to the peer. Both the caller and the callee independently allocate on a TURN server and send relayed transport addresses to each other to be reached on.
Basically, TURN can do bidirectional data flow, but with ICE between two symmetric NAT's, it wont. Is this correct?
Its a bit complicated.... bear with me. Reading just the TURN RFC isn't enough, you need context from RFC 5245 on ICE too.
The following scenario is the baseline case:
client A allocates a relay address 8.8.8.8:43739, sends it to client B
client B sends a UDP packet to 8.8.8.8:43739
TURN servers wraps the packet in a stun message, sends it to client A
Now as you say, typically client B will also allocate its own relay address and send it to A. Why isn't that used all the time (or half the time)? The priorities of the candidates are equal after all.
However the candidate pair priority which determines which pair to pick includes a factor which acts as a tie-breaker:
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
Where G>D?1:0 is an expression whose value is 1 if G is greater than
D, and 0 otherwise.
This means the pair where the callers (assuming its the controlling agent) relay address is used has a higher priority than the pair with the callees relay address.
Additionally, there is another candidate in the game here for the port client B uses to send to port 8.8.8.8:43739. This will typically be from one of the local candidates and the TURN server sees (and puts into the data indication) the public (post-nat) ip of client B. On client A this will show up as a remote srflx candidate -- which has a higher priority than a relayed candidate and will therefore be used.
Now if B is behind a symmetric NAT (I think) the TURN server will see a different port from client B than anything for which client A has added a permission. This will typically mean the TURN server will drop the packet and that pair won't work.
If client A is not behind a symmetric NAT, the baseline process will be repeated in the other direction. Slightly less priority but its the same in terms of latency so users won't notice.
If both clients are (and now we are finally at the case you're asking about) are behind symmetric NAT, neither will work and a relay-relay pair will be used. This is fairly rare (<1% probably) and the latency impact is typically insignificant even when both clients are on different TURN servers.
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.
This looks like it is a well known WiFi issue:
Quoted from 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.
This article has more information:
http://hal.archives-ouvertes.fr/docs/00/08/44/57/PDF/RR-5947.pdf
One very interesting side-effect of the multicast implementation (at the WiFi MAC layer) is that as long as your receivers are wired, you will not experience any issues (due to the acknowledgement on the receiver side, which is really a unicast connection). However, with WiFi receivers (as in my case), packet loss is enormous and completely unacceptable for audio.
Multicast does not have ack packets and so there is no retransmission of lost packets. This makes perfect sense as there are many receivers and it's not like they can all reply at the same time (the air is shared like coax Ethernet). If they were all to send acks in sequence using some backoff scheme it would eat all your bandwidth.
UDP streaming with packet loss is a well known challenge and is usually solved using some type of forward error correction. Recently a class known as fountain codes, such as Raptor-Q, shows promise for packet loss problem in particular when there are several unreliable sources for the data at the same time. (example: multiple wifi access points covering an area)
I have an application that is sending some UDP packets using multicast. I looked at the network traffic and there seems to be a lot of ancillary packets related to using multicast. I don't totally understand it, but does multicast by nature result in MORE network traffic. If so how can I throttle this down?
x
Other than the Multicast group join/remove messages, there are no ancillary messages created from you sending multicast data.
However, NIC's, routers, switches, printers, etc. all usually send some kind of multicast traffic, which is probably what you are seeing if you record the traffic.
In short, you need the networking equipment that forwards traffic between the client nodes to take care of this. Those vary depending on the network topology but would normally be:
Ethernet switches
IP routers.
Switch / router (implements functionality of a switch & router)
There are multicast control protocols such as IGMP but of course the source nodes and/or intermediate nodes (e.g. switches) must comply to these control protocols.
And YES multicast result in more network traffic : this is why plain Ethernet hubbing is practically extinct and additions to IEEE Ethernet such as VLANs are prevalent nowadays.
This is probably best addressed on some other sites (maybe this SO-style site PacketDrop).
LLC packets means you probably have sub-netting on your local segment, usually this doesn't mean extra packets though. You should change the network to a full class C if you want to remove LLC. On regular packets LLC or SNAP adds a 8-byte header.
http://ckp.made-it.com/ieee8022.html
I'm attempting to send multichannel audio over WiFi from one server to multiple client computers using UDP broadcast on a private network.
I'm using software called Pure Data, with a UDP broadcast tool called netsend~ and netreceive~. The code is here:
http://www.remu.fr/sound-delta/netsend~/
To cut a long story short, I'm able to achieve sending 9 channels to one client computer in a point-to-point network, but when I try to do broadcast to 2 clients (haven't yet tried more), I get no sound. I can compress the audio and send 4 channels compressed (about 10% size of uncompressed) over UDP broadcast to 2 clients successfully. Or I can send 1 channel over UDP broadcast to 2 clients, with some glitches.
The WiFi router is a Linksys WRT300N. All computers are running Windows XP. The IP addresses are 192.168.1.x, with subnet mask 255.255.255.0 and the subnet broadcast address: 192.168.1.255.
I'm curious - what happens to UDP broadcast packets in the router?
If I have a subnet mask of 255.255.255.0, then does the router make 254 packets for every packet sent ot the broadcast address?
My WiFi bandwidth is at least 100Mbps, but I can't seem to send audio of more than around 10Mbps over UDP broadcast to multiple clients.
What's stopping me from sending audio up to the bandwidth limit of the WiFi?
any suggestions for socket code modifications, network setups, router setups, subnet modifications... all very much appreciated!
thanks
Nick
Your problem is caused by the access point's rate control algorithm. With unicast the access point tracks what data rate every particular receiver can reliably receive at, and sends about that rate. With multicast the access point does not know which receivers are interested in the data, so simple access points send the data at the slowest possible rate (1Mb/s). Better implemented access points may send the data at the rate that the slowest connected client is using, and the best access points use IGMP snooping to see who's receiving each IP multicast stream, and they will choose the slowest rate out of the receivers for that stream.
The simplest solution is to not use multicast when you have a small number of WiFi receivers.
Are all parties connected via WiFi or is the sender using a
wired connection to the Access Point? Broadcast data will
be transmitted as unicast data from a station to an access
point and the access point will then retransmit the data
as broadcast/multicast traffic so it will use twice the
on-air bandwidth compared to when the sender sits on the
wired side of the AP.
When sending a unicast frame the AP will wait for an ACK
from the receiving station and it will retransmit the
frame until the ACK arrives (or it times out). Broadcast/multicast
frames are not ACKed and therefore not retransmitted.
If you have a busy/noisy radio environment this will
cause the likelyhood of dropped packets to increase,
potentially a lot, for multicast traffic compared to unicast
traffic. In an audio application this could certainly be audible.
Also, IIRC, broadcast/multicast traffic does not use the
RTS/CTS procedure for reserving the media which exarbates
the dropped packets problem.
It could actually be the case that multiple unicast streams
work better than a single multicast stream under less-than-ideal
radio conditions given that the aggregated bandwidth is
high enough.
If you can I would suggest that you use wireshark to sniff
the WiFi traffic and take a look at the destination address
in the 802.11 header. Then you can verify if the packets
are actually broadcast or not over the air.
Your design is failing due to a common misconception with WiFi speeds. With 802.11n the number 300mb/s is the link speed, not the actual bandwidth available for user data or even the IP layer. The effective bandwidth is closer to 40mb/s best case, have a look at the FAQ on SmallNetBuilder.com that discusses this in further detail.
http://www.smallnetbuilder.com/wireless/wireless-basics/31083-smallnetbuilders-wireless-faq-the-essentials
I'm curious - what happens to UDP broadcast packets in the router? If I have a subnet mask of 255.255.255.0, then does the router make 254 packets for every packet sent ot the broadcast address?
No the "router" doesn't make 254 individual packets. Furthermore, I suspect the protocol leverages "multicast" addresses rather than using a "broadcast" address.
Since broadcast/multicast traffic can easily be misused, there are many networking equipment that limit/block by default such traffic. Of course, some essential protocols (e.g. ARP, DHCP) rely on broadcast/multicast addresses to function and won't be blocked by default.
Hence, it might be a good thing to check for multicast/broadcast control knobs on your router.