Re: Determining "default" address from Rendezvous resolve
Re: Determining "default" address from Rendezvous resolve
- Subject: Re: Determining "default" address from Rendezvous resolve
- From: Peter Sichel <email@hidden>
- Date: Mon, 23 Sep 2002 10:12:17 -0400
At 1:56 AM +0200 9/22/02, Ragnar Sundblad wrote:
How about the situation where each of the two communicating
machines has one gig ether and one wlan connection, bridging
or routing wlan bases, on totaly two or four different ip
subnets, and each on each side of a router in between like
below. What should you choose then?
example 1, bridging or routing access points:
+--- GE ---+ +--- GE ---+
m1 +--+-- Rtr --+--+ m2
+-- WLAN ----AP AP---- WLAN --+
example 2, bridging or routing airports too:
+--- GE ---------\ /--------- GE ---+
m1 Rtr m2
+-- WLAN ----AP--/ \--AP---- WLAN --+
(These examples don't apply for subnet limited discovery,
I assume we don't want to limit ourselves with that.)
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.
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.
I'm not convinced Rendezvous should create an application layer
convention for choosing between routes when the Internet protocol
suite already has an existing infrastructure and technology base for
this purpose. That's not to say a better solution isn't needed,
but rather, that any solution that addresses adhoc routing should
try to fit within the context of existing Internet protocols
and concepts.
We both agree a first step is to try and select the preferred local
interface based on the network number.
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?
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).
The big advantage is we didn't need to invent any new Internet
protocols or conventions (to be ratified).
- Peter
_______________________________________________
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.