Date: Fri, 17 Sep 1999 15:49:05 -0600 From: Chris Fedde <cfedde@fedde.littleton.co.us> To: Mitch Collinsworth <mkc@Graphics.Cornell.EDU> Cc: "Mark Jones" <mjones@mco.net>, freebsd-questions@FreeBSD.ORG Subject: Re: multi-homed Message-ID: <199909172149.PAA36738@fedde.littleton.co.us> In-Reply-To: Your message of "Wed, 08 Sep 1999 12:48:45 EDT." <199909081648.AA244489326@broccoli.graphics.cornell.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry to have taken so long to get back to you on this. I havent looked in
this folder for some time.
Mitch Collinsworth writes:
+---------------
| Ok, this I didn't know and is why I phrased my initial response in the
| form of a question. To allow someone who knew for sure to either confirm
| or correct me. Thank you. Just out of curiosity, is there a source
| for a more definitive description of "most modern TCP clients"?
+---------------
It seems that I over stated the case slightly...
The Host Requirements Standard (RFC 1123) states:
2.3 Applications on Multihomed hosts
When the remote host is multihomed, the name-to-address
translation will return a list of alternative IP addresses. As
specified in Section 6.1.3.4, this list should be in order of
decreasing preference. Application protocol implementations
SHOULD be prepared to try multiple addresses from the list until
success is obtained. More specific requirements for SMTP are
given in Section 5.3.4.
The problem here is the word SHOULD. In standards speek it means that
the implementer may choose not to implement this. Most programmers choose
not to implement MAY and SHOULD features. I set up a little test
round robbin here. This demonstrates that telnet at least implements the
protocol this way.
$ dig +pfset=0x2020 He.fedde.littleton.co.us
He.fedde.littleton.co.us. 1H IN A 10.0.0.6
He.fedde.littleton.co.us. 1H IN A 10.0.0.5
He.fedde.littleton.co.us. 1H IN A 10.0.0.4
He.fedde.littleton.co.us. 1H IN A 10.0.0.3
$ telnet He.fedde.littleton.co.us
Trying 10.0.0.5...
telnet: connect to address 10.0.0.5: Operation timed out
telnet: connect to address 10.0.0.4: Operation timed out
telnet: connect to address 10.0.0.3: Operation timed out
telnet: Unable to connect to remote host: Operation timed out
I tested Netscape at it appears that it does not bother to implement
this behavior at all. That is a shame because it makes the network
that much less reliable. But at least it does use the next address
in the round robin on each subsequent click of the same url.
More than once I've been blindsided by this kind of situation.
For example routers MUST send an ICMP unreachable messages when
they cannot forward a packet. Unfortunately clients MAY choose to
use the information provided by ICMP messages. This is another
example where an opportunity at robustness has been lost because of
implementation expedience.
Still the basic argument holds. Round robin over a diverse deployment of
hosts is usually a superior configuration to concentrating resources in one
site.
chris
__
Chris Fedde <cfedde@fedde.littleton.co.us>
303 773 9134
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909172149.PAA36738>