Re: Determining "default" address from Rendezvous resolve
Re: Determining "default" address from Rendezvous resolve
- Subject: Re: Determining "default" address from Rendezvous resolve
- From: Ragnar Sundblad <email@hidden>
- Date: Mon, 23 Sep 2002 20:03:29 +0200
--On den 23 september 2002 10:12 -0400 Peter Sichel <email@hidden>
wrote:
I believe Rendezvous is limited to subnet discovery.
Notice Rendezvous is carefully designed to use existing
Internet concepts and protocols with the goal of
being widely accepted as a universal standard.
Yes, with Apple's currently available tools (as far as I know),
but ZeroConf allows for a server infrastructure too.
Also, from
http://www.zeroconf.org/Rendezvous/:
-----
How does Rendezvous / DNS-SD scale to networks bigger than a single link?
...
The first release of DNS-SD for Mac OS X concentrates on Multicast DNS for
single-link networks, because those are the networks worst served by
current IP software. Future versions will add Dynamic Update and unicast
query support.
...
-----
Routing is the Internet layer responsible for choosing the
"best" network path between hosts. The key to efficient routing
in TCP/IP is that IP address are carefully assigned based on
where and how devices are attached to the network.
Yes, the problem with this design is that it is done many years
ago with the thought of end hosts only having one interface
in mind. That is not the case anymore, and gives you all kind
of problems when you try to build networks with redundancy
for example.
We really need a new design here for allowing end hosts to
have multiple interfaces in a usable way. Some work is done
within IETF on this, I don't know the status of it though.
One of the problems is of course the one we are facing here,
choosing which way is the "best" (and best in what sense and
blah blah blah...).
We both agree a first step is to try and select the preferred local
interface based on the network number.
(Or rather, based on the local network interface bandwidths, but yes!)
If we accept your argument that this is not sufficient, that is,
residential LANs cannot always be designed to assign private IP addresses
in an efficient manor. Then the next question becomes what other
techniques are available?
I actually haven't even considered private networks (since they
should be equivalent except for the evil part of their
properties).
We might use ping for example to probe the link rate to each
candidate IP address and choose the one with the best response.
The Link Rate tool in IPNetMonitorX is one such example.
It sends a ping of 52 bytes and then 1052 bytes and measures
the round trip time (RTT) of each. The additional RTT to send
the longer packet reflects the amount of time it takes to send
an additional 1000 bytes there and back. The link rate is
<additional-bytes>/<half-the-additional-RTT>. In practice,
this works pretty well for directly attached subnets. The
trick is to send a few pings of each length and use the best RTT
(to minimize the effect of momentary congestion).
That is also a good solution for guessing something reasonable!
One problem with this approach is that it could give bad answers
due to temporary congestion or other problems, but if one also
retest every now and then "reroutes" one could most of the time
have a pretty good connection (given that the protocol/application
allows you to reconnect in another "route" of course).
Another problem could be that people might not like the idea of
wasting bandwidth on measuring network performance, but I
personally don't care as long as it a negligable amount.
One could even design it into the transmission protocol so that
it is done as part of exchanging data on a open connection.
/ragge
_______________________________________________
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.