Re: broadcast address of a network interface
Re: broadcast address of a network interface
- Subject: Re: broadcast address of a network interface
- From: Josh Graessley <email@hidden>
- Date: Mon, 09 Feb 2009 09:58:30 -0800
Your best bet really is to use something like Bonjour to discover the
service running on all the other devices, open individual TCP
connections to all of the clients and send data to over each TCP
connection. Just because the feature is "broadcast" doesn't mean the
implementation needs to do that under the covers.
Multicast and broadcast over WiFi is extremely expensive. As someone
pointed out, the access point doesn't know which wireless clients want
the multicast/broadcast. Most unicast packets over the WiFi link are
actually acked and retransmitted if they didn't make. Multicast/
broadcats are not. To increase reliability, they're transmitted at a
very slow rate (often 2megabit) instead of 54 or whatever. The
multicast packet takes about 25 times as long to transmit. In other
words, in the time it takes to send a single multicast packet, the
network could have sent 25 unicast packets. In the real world you
don't really get 54 megabit and there's some overhead at the 802.11
layer with the acknowledgements and whatnot but even if you drop that
optimistic 25 to 1 number down to 10 to 1, you're probably still going
to see a performance win using unicast.
Bonjour uses a trick where it multicasts a question and sets a special
bit to request that the clients respond using unicast. Normally, a
multicast DNS answer to a query is sent using multicast to make
duplicate detection quicker. When a computer joins a WiFi network for
the first time or upon waking from sleep, it often has a number of
open browse requests. Browsing for all of those services at once tends
trigger a large number of answers. mDNSResponder will set a special
bit requesting that answers be unicast. After the first query that
collects lots of unicast answers, mDNSResponder sends another query
allowing multicast answers for clients that don't understand the
unicast answer bit. The query includes a list of known answers
received via unicast so all those responders that see their answer
already in the known answers section don't ever need to send a
multicast. There is an exception where a responder will send a
multicast if it hasn't sent a multicast in a while to help with
duplicate detection still occurs.
-josh
On Feb 9, 2009, at 9:20 AM, Joel Reymont wrote:
Let me take a step back then. I would like to "broadcast" audio
packets from my iPhone to other Macs (including iPhones), without
connecting to every iPhone individually.
What is the best option?
Is BiDir PIM available to me on the iPhone? Should I go with UDP LAN
broadcast?
I know PIM is available to me on my home LAN because I have a Cisco
877W but I'd like my app to have a bit more sales potential :-). I
also noticed that the Cisco 877W firmware that allows Bonjour, does
not come with multicast and vise versa. I would hate to enable
multicast and loose my printers and file sharing!
Last but not least, I can't seem to be able to get hold of a
broadcast address by enumerating the interfaces, whether on my Mac
or iPhone. ifa_broadaddr is null and so is ifa_netmask!
Thanks, Joel
On Feb 9, 2009, at 5:12 PM, Marshall Eubanks wrote:
Because of this, some wireless AP vendors either don't send
multicasts at all, or don't by default. Even though multicasts
sources on the wireless LAN are less of a problem, they are
sometimes blocked as well. So, you will need to address these
issues somehow.
The particular "push to talk" problem you mention is frequently
done using BiDir PIM now-a-days, at least on wireline networks. See
---
http://tinyco.de
--- Mac & iPhone
_______________________________________________
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
_______________________________________________
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