Re: UDP and OT
Re: UDP and OT
- Subject: Re: UDP and OT
- From: Quinn <email@hidden>
- Date: Thu, 12 Dec 2002 12:45:50 +0000
At 12:08 +0000 12/12/02, email@hidden wrote:
> You should also use the IP_BROADCAST option on the client and
probably the IP_REUSEADDR option on the server. See IM:NWOT for
details.
Why would you set IP_BROADCAST on a client, documented say to have
permission on sending them, so I thought Server ???.
The documentation says:
IP_BROADCAST
Request permission to send broadcast datagrams. (UInt32)
Set this option to T_YES to request permission to send broadcast
datagrams. Specify T_NO to disable this option. This option is
disabled by default.
I read that to mean that you have to set it in order to send
broadcasts. Seeing as the client is the machine sending broadcasts
(trying to look for all the servers), that's where you'd set it.
I was planning on using IP_DONTROUTE as well, so my packets don't get
sent out. Although most routers don't send on UDP packets regardless of this
setting.
In this case I would just set the IP_TTL to 1.
> Finally, I recommend you stay away from broadcasting on a subnet. If
you want to do service discovery, use multicasts. Better yet, use
Rendezvous.
Would love to use Rendezvous, but I need to be 9.x as well.
Well, if you're feeling adventurous, you could incorporate the Darwin
Rendezvous code into your application. The Rendezvous code is split
into a common core (which is in portable C) and a platform layer.
Writing a platform layer isn't too difficult, and we actually include
a Mac OS 9 platform layer as part of the source distribution.
<
http://developer.apple.com/darwin/projects/rendezvous/>
The advantage of using Rendezvous is that there are lots of
subtleties related to implementing a reliable and non-chatty service
discovery protocol, and Rendezvous takes care of them all for you.
Although, I am aware that broadcasting on a subset you cannot relay on
delivery. Its should be the most efficient on the amount of traffic on the
network, as it would be in effect one packet making the rounds, which is
sent out and each machine will just notice its there. This relies on only
one machine sending these, not all of them. Is this not true ???.
I don't understand what you're saying here. My suggestion was to use
IP multicast instead of using IP broadcast. The advantage of using
multicast is that, when you send a packet, only machines that are
subscribed to that particular multicast address will receive it. The
rest of them will filter it out in hardware. OTOH, if you broadcast,
every machine receives the broadcast and, if you're software isn't
running, throw the packet away in softwar.
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.