Re: Mirror Negotiation

On Mon, 9 Dec 1996, Chanda Dharap wrote:

> Someone said:
> >Isn't mirroring just a special case of caching?
> 
> Maybe in the implementation, but not in functionality.
> 
> Mirroring (replicating) is geared towards improved availability while
> caching is geared towards improved performance.

Mmmm..I would see it differently. I know that when I go 'mirror shoppping'
it is not because of availability (which is almost a non-issue with HTTP
instead of FTP - 'max users' is almost meaningless with HTTP) but
performance. An overloaded site does not usually become *unavailable* per
se with HTTP - it becomes *unacceptably slow*.

So I would say that HTTP mirroring *is* a special case of caching in
functionality - not just implementation.

Note: The discussion about geography is somewhat off mark, IMHO. I live
and work in Silicon Valley - but often find it *much* faster to pull some
things (not to mention any names, but Microsoft's mirrors are a prime
example) across the continent from a mirror than from servers that are
only 10-15 miles from me - the local servers are too overloaded and
network congestion often differs not just by *where* something is - but by
*which* backbone you have to go through to reach it. MCI is notorious for
mid-afternoon network flaps that makes *anything* you have to reach
through them a 'long' way away.

An effective 'mirror selection' protocal would have to probe sites to
find out response times from where the browser is. A first order
approximation might be the addition of a 'PING' method. By measuring the
RTT for the response to the HTTP 'PING' you would get a combined idea of
network distance + server load - at a cost of a short HTTP
transaction to every server in the mirror list. You could fine tune it by
allowing the response to include a server's status line that would tell
the client *more* about the server's load and performance capabilities.

-- 
Benjamin Franz

Received on Tuesday, 10 December 1996 08:33:03 UTC