Re: UDP Broadcast uses random source ports
Re: UDP Broadcast uses random source ports
- Subject: Re: UDP Broadcast uses random source ports
- From: Chad Williams <email@hidden>
- Date: Wed, 31 Aug 2011 20:16:40 -0700
- Thread-topic: UDP Broadcast uses random source ports
Thank you for all the replies. I will be messing around with all the
suggestions to see what works best for my application. Now I just need to
get a moment away from my day job to programĀI'll let everyone know how it
turns out.
Thanks, Chad
On 8/31/11 11:15 AM, "james woodyatt" <email@hidden> wrote:
>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:
>m
>
>This email sent to email@hidden
>
_______________________________________________
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