• 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: Broadcast Protocols
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Broadcast Protocols


  • Subject: Re: Broadcast Protocols
  • From: Andreas Fink <email@hidden>
  • Date: Fri, 21 Sep 2012 20:34:31 +0200

Title: Broadcast Protocols


On 21.09.2012, at 20:17, Gordon Apple <email@hidden> wrote:

Not exactly a Mac question, unless it is.  I have not been able to find the answer to this via Google, or elsewhere.

What I would like is a means to broadcast, either over a network or especially over a WiFi channel, a single stream (possibly UDP) which can be (optionally) received by anyone on the LAN or within WiFi range.  Unfortunately, this does not fit the usual individual connection/socket based architecture of modern networking.  The application is primarily for the distribution of video and other signals, sent to everyone in a classroom or auditorium for reception on a lapTop, iPad, whatever.  My limited understanding of “multicast” is that this is a router function, where a single stream is replicated to each receiver.  This does not work for WiFi due to spectrum capacity limitations.

If you use a broadcast, you basically send packets to all nodes in a subnet. You do this by originating from the broadcast address and all nodes will get the packet. That's how broadcasts work.
However there's a catch in this. This means that all nodes in the subnet have to process the data, if they want it or not which might not be intentional. Secondly if you are in a Wifi area where you use WPA2, then the access point has to replicate the packet for every single user as everyone has it's private encryption key. This is not the case with WEP where everyone shares the same key or if you use it unencrypted.
Secondly, your broadcast is limited to your subnet you are in.

There are other mechanisms such as PIM to make broadcasts on routers work with multicast address so if you have a large network where you want to send out data to many but you don't want to duplicate at the source but hopefully very close to the receiver (if needed), then PIM can manage a multicast address (which is some kind of managed broadcast address).  So this saves bandwith on the path between the routers. My understanding is that in a multicast, on the last bit, its basically sent out to a joint ethernet address which everyone listens to who is interested in this multicast. So this would work for your scenario, at least when the last bit is a point to multipoint capable medium such as ethernet. I would have to dig deeper into PIM to verify this assumption however.

I do agree that the use of multiple TCP or UDP streams is a terrible waste of bandwidth. There are however some reason why its done like this often:
a) the originator of the broadcast distributes world wide and has no control over the distribution network
b) the receiver have different capabilities and bandwidths. You do not stream a full H264 HD video to a iPhone first generation with a resolution which can't handle all this data and is currently on a EDGE connection.
c) the receiver might be behind NAT and as such UDP broadcast streams might not work properly, hence the favored  "lets download a bit of the stream over HTTP mode every time" which works over proxies, firewalls , NAT etc.

Proper multicasts are in the internet standards since a long time.
In today's IPv6 world it's time to get rid of NAT and all those ugly workarounds. 

Andreas FInk

 _______________________________________________
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: 
 >Broadcast Protocols (From: Gordon Apple <email@hidden>)

  • Prev by Date: Broadcast Protocols
  • Next by Date: Re: Broadcast Protocols
  • Previous by thread: Broadcast Protocols
  • Next by thread: Re: Broadcast Protocols
  • Index(es):
    • Date
    • Thread