• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: UDP Broadcast uses random source ports
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

References: 
 >Re: UDP Broadcast uses random source ports (From: james woodyatt <email@hidden>)

  • Prev by Date: Re: UDP Broadcast uses random source ports
  • Previous by thread: Re: UDP Broadcast uses random source ports
  • Next by thread: Re: UDP Broadcast uses random source ports
  • Index(es):
    • Date
    • Thread