Re: Determining "default" address from Rendezvous resolve
Re: Determining "default" address from Rendezvous resolve
- Subject: Re: Determining "default" address from Rendezvous resolve
- From: "Dean Dauger" <email@hidden>
- Date: Fri, 20 Sep 2002 10:01:59 -0700
Hi,
Thanks for your help.
>
As I understand it, Rendezvous operates on directly attached
>
IP subnets. Thus it should be possible to use the System Configuration
>
Framework to identify the IP address of the primary interface on the
>
localhost and use this to select the desired peer.
>
Since you don't really have much control over how the remote peer
>
is configured or views the network, the concept of "primary" interface
>
on the remote peer is ambiguous at best.
Yes, that ambiguity is the issue here.
>
What you can do is decide
>
which local interface you prefer to use. "Ethernet built-in (en0)" is
>
probably faster than "AirPort (en2)" when it's available.
I basically have that much implemented already. I can illustrate using the
following scenario:
Alice's Mac is connected via 100BaseT and its Airport card to the same
network DHCP-managed and bridged by one Airport Base Station. Bob's Mac is
also connected to this network, but only via 100BaseT. The Base Station
assigns Alice's Mac two IP addresses, one for each interface, while Bob's is
assigned only one. My app is running and Rendezvous-registered on both.
Bob wants to browse for Alice's Mac, so both Macs can be used for a
computationally- and communications-intensive cluster computing job.
Therefore, it's important to connect via the "best" interface. When my app
on Bob's Mac tries to resolve Alice's Mac, it gets two IP addresses. Which
one does it choose? With the API as it stands, it appears that there is no
way to tell which is the best choice.
My workaround at the moment is to have my app on Alice's Mac supply that
extra bit of information by opening only one listener port on the "primary"
interface, then have Bob's Mac inquire on one address at a time until it's
found. (If Alice disconnected the 100BaseT before Bob's resolve, my app
automatically listens on the remaining interface, and there's no ambiguity.)
But it seems to me that the ZeroConfig/Rendezvous on Alice's Mac could
easily have suppled that extra information to Bob's Mac during the resolve
in the first place (maybe by attaching a rating to each address if they came
out of order), making the process simpler for me and quicker for Bob.
This is not just for my application. Replace Alice's Mac with Alice's
ZeroConfig-equipped printer connected via 100BaseT and Airport. The printer
would probably have to have listener ports on both interfaces. Bob's Mac
might happen to choose the printer's Airport IP address first, and then Bob
will wonder why Bob's print job is so slow and everyone else will wonder why
the Airport network is bogged down today, but not the day before.
But if the Rendezvous/ZeroConfig implementation had told Bob's Mac which one
to use, then all would be well.
>
The Address Scan tool in IPNetMonitorX (from my website) does
>
something like this. The target popup lists the attached
>
networks and localhost addresses.
>
>
- Peter Sichel
>
www.sustworks.com
Thanks for the tips! I'll have to have a look at that one.
Dean
_______________________________________________
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.