Re: UDP Broadcast uses random source ports
Re: UDP Broadcast uses random source ports
- Subject: Re: UDP Broadcast uses random source ports
- From: james woodyatt <email@hidden>
- Date: Wed, 31 Aug 2011 11:15:55 -0700
On Aug 31, 2011, at 07:56 , Quinn The Eskimo! wrote:
>
> Actually, multicast is a win in pretty much all circumstances. This breaks down as follows:
>
> o On all common networks (Ethernet, Wi-Fi, you name it), a multicast consumes as much network resources as a broadcast.
>
> o Most MACs [1] will filter out multicasts that the host isn't listening for. This is typically done using a hash table in the hardware.
>
> o If the hash table is full, the filtering has to be done by software. However, this worst case is no worse than broadcast's typical case.
>
> So, in all cases multicast is no worse than broadcast, and in some cases it can be better.
>
> The above discussion assumes link-local multicast; once you go off the local network, things get much more complex.
For the sake of completeness, I will make the following three points of clarification about multicast vs. broadcast:
p1. On IEEE 802.1 links, e.g. Ethernet, Wi-fi, bridged networks, and the like, the broadcast destination is just a distinguished multicast address assigned by the standard to all the stations on the link.
p2. On some networks built with carrier-grade equipment, the switches and other nodes in the forwarding plane are aware of IP-multicast protocols, i.e. they can snoop the IGMP and MLD messages and forward multicast at line rates with hardware cut-through to just the ports where they have recognized one or more group members. That optimization doesn't work for IPv4 broadcast, for which there is no control protocol.
p3. There is no broadcast in IPv6. There is merely a distinguished multicast identifier for All IPv6 Nodes, which is almost functionally equivalent to IPv4 broadcast when used in the link-local multicast scope, except that it happens to work properly with IP-multicast aware layer-2 forwarding.
p4. If you write your code to depend on the simpler broadcast semantics of IPv4 rather than the more complicated multicast semantics, then you'll pay for it later when you need to extend support to IPv6, where broadcast is not available.
In conclusion, IPv4 broadcast UDP must be destroyed. Please stop using it. That is all.
--
james woodyatt <email@hidden>
member of technical staff, core os networking
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden