[cc's trimmed]
On Sat 20 Sep, 1997, Anthony Baxter <arb@connect.com.au> wrote:
>You can install multiple ones in a group to sit alongside each other and
>load share - but the way the sharing is done is extremely simple (takes
>a hash of the hostname) - so all of www.microsoft.com would go to the same
>box.
Are you sure? It implied that it did it based upon allocated chunks of address
space to different units. (which would make more sense. It's the router that
does the distribution.) So as Microsoft use many addresses for their
servers it could get very messy. Questions I'd like to have answered are 1.
Does it look at Host headers to achieve better/ more efficient caching? 2.
Does a request to a web site appear to come from the cache engine or from the
client (I'd presume the former, but you never know.) 3. What happens when a web
site decides to block your caches? (this has happened, and I never got a reply
from the web site concerned.) 4. How configurable is it with respect to things
you don't want to cache (the usual cgi-bin, queries ?, plus such nasties as
those that embed cookies in non-query URLs.) 5. How close to HTTP/1.1 cache
behaviour is it?
>It's a neat idea, and most of the above are to be expected from a first
>release of the product. I hope cisco release the WCCP (web cache control
>protocol - the protocol between the router and the caches) as a public
>specification.
I too would like to see a public spec of this. From the marketting materials it
has some interesting features, not least of which is that the caches and router
between them decide where to send each chunk of data, and they can decide to
move allocations around between different units, as and if you add more! This
is something that simple hashing schemes (such as Microsoft's CARP) don't
address.
Oh, I also like that if you reallocate, the new engine collects any cached data
for that chunk from the one that was previously responsible. An interesting
idea, if it works.
[Hmm, the squid-users list is probably the wrong place for this discussion.
Nevermind, for now.]
James.
Received on Sat Sep 20 1997 - 07:02:51 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:37:07 MST