From: mitra@pandora.sf.ca.us (Mitra)
Subject: Re: Selecting URL from "equal" sites
Date: Wed, 27 Apr 1994 15:58:20 GMT
Message-Id: <CoxDp8.FHB@pandora.sf.ca.us>
Dirk Herr-Hoyman (hoymand@gate.net) wrote:
: We've been chatting a bit about what might go in a URC to allow for URL
: selection. There's one case we haven't dealt with and it's one that's in
: front of us right way. How can you choose between "equal" sites? For
: example, how does one pick an archie server or GNN server?
I think this intelligence belongs in the clients, not in the servers.
: The "correct" URL in this case would be "closest" to me. Close could be
: hops or response time or some other metric. This is a tough nut to crack,
: but without it, we are likely to beat up on one server or pick a bad one.
: There are 2 cases of equal servers that I am seeing:
: 1. Geographically/network. distributed.
: 2. Local load sharing.
: This first case is like archie servers, the 2nd might be multiple systems @
: NSCA for their WWW home page.
: I don't see that there's anything a publisher could put in the URC that
: would help for #1. Knowing the physical location doesn't always work. Top
: level domainnames are not always close. The only thing I see working, in
: my understanding of TCP/IP, would be to probe the net ala traceroute. But,
: that might really slow the resolution down (imagine probing ALL the archie
: servers when the link to australia is slow). The URC server could maintain
: a table of response times, but that doesn't necessarily apply to the
: client's route.
: For #2, the URC server could perhaps randomly order the URLs in the UYRC,
: presuming that the 1st one will be chosen. I guess this is the fallback
: strategy for #1, where the URLs that are "close" (all archie servers in
: North America) are grouped and then returned in a random order. Then, a
: geographic location might be useful.
I think the randomness belongs in the clients, what is "equal" to one
user, might not be to another. For example - I might not care between
Content-Type: image/jpeg and image/gif, but someone else might. Even
half way intelligent clients are going to do this, because to always
pick the top one is going to usually get slower response.
: Anyone have a good idea here for the archie case?
The archie case, actually falls most likely into a load-sharing case,
not a "closeness" case, since the volume of material shifted is fairly
small, but the servers are frequently overloaded. There have been a
number of ideas for dealing with this, one of which is to pick an
address like "archie.svc.int" and then put a smart DNS resolver on
"svc.int" that monitors the load on all the archies and returns the IP
addresses sorted by load, or if loads are equivalent, sorted by
"closeness".
In other words .... I'm suggesting the solutions to these problems belong in
something other than the URC or the URN->URC resolver.
- Mitra