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: Sun, 22 Sep 2002 01:56:14 +0200
--On Fri, 20 Sep 2002 15:56:31 -0400
Peter Sichel <email@hidden> wrote:
In this case, the design of your network is part of the problem.
If you were to route between your wireless and 100BaseT LAN instead
of bridging, it would be easy to distinguish them based on their
IP subnets. The whole point of routing is to segregate or route
traffic more efficiently. Bridging is not the best choice in this
situation.
Maybe so, but routing to the wlan is more complicated for
everybody, inhibits wlan roaming (without vpn or mobile ip
or something like that), and won't solve many problems
anyway.
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 think it would be simpler and more robust to configure your AirPort
Base Station to route between your networks, and design your Rendezvous
application to consider the network number in choosing the desired route.
It would be much better if the networking code in the os could
default to do the most often right thing so that not every
application have to do it themselves, and maybe one could also
trim the behaviour for an entire machine as a whole. Compare with
apple's way of letting the route do the local network and the
default route point to the fastest interface available, and
that you (Peter) said you preferred en0 over en2 in some
program.
There are several ways to try to guess what to do, I have made
contact with several of those, and they all are a pain in the
rear in some situations.
So, the facts are these for a typical ip node:
- We don't know anything about the network topology
- Any guess could be wrong
So we have to guess (but allow for other user trimming).
Using the fastest connection localy is probably a good choice,
as has been suggested.
Now, what about what address to connect to?
Networks are often designed with as few bottlenecks as possible,
so it is a good guess that a faster network have better
connection to the rest of the network than has a slower network.
So if we could get the very same information about the other
node's network connections too, a guess that the faster connection
in that end is as good a guess as in the local end.
I like Dean's solution, I think that is as good as gets with
simple means. If there was support for it in the OS(es) and
protocols that would be bood.
The only bad thing with it is that we all know that it is not
an always correct soloution to the problem, though noone seems
to know what would be
(all nodes having topology info (with updated load info too?)?,
measuring each combination of node addresses with a load test?,
inventing a "ICMP Bandwidth Discovery"?, ...).
/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.