Re: Microsoft CRAP^H^H^HARP

From: Gregory Maxwell <>
Date: Sun, 12 Oct 1997 19:02:36 -0400 (EDT)

On Sun, 12 Oct 1997, Henrik Nordstrom wrote:

> Here are my 2 cents of thought on CARP vs IPC...
> Well, yes CARP is probably better in the situation that Microsoft is
> thinking about: A cache ARRAY (that is a large number of machines,
> acting as a single cache server, all in the microsoft filofosy that the
> more machines the better).

And just reinstall to fix it..

> ICP is designed with a cache-hierarchy in mind, and assumes that at any
> given single point in the hierarchy only one or max two ICP servers is
> needed (two only to provide fault tolerance).
> So, yes. If you are thinking about building a LARGE cache array (many
> machines acting as a single point cache, not a hierarchy) then
> hash-based routing is probably preferable.

Then you use a differnt form or icp for this.. This is something that is
good for supporting end clients.. ICP is for hierarchies.. This is apples
and oranges..

> If building a hierarchy, with WAN links between the caches, then cache
> redundancy is actually preferred, since the WAN links are part of the
> bottleneck. It does not matter that the same pages are stored on 20
> different servers, since these servers serves 20 different groups of
> people.

Yes, ICP and CARP are differnt things.. There is a place for both

But IMHO there is less place for carp.. Imagine a large ISP.. 10 computers
form the cache.. They are all connected to ethernet and the ethernet
connects to termserver to ISDN users... CARP would be good to distribute
the load.. But it would not be that nessassary: Use RR-DNS (or some other
typical RR method) and run the caches as proxy only.. The extra latency
from fetching from another box and waiting for the ICP is tiny..

This about the only real use of it.. A single site.. This could be done
with ICP and proxy-only.. Though a true distribution method would be
Received on Sun Oct 12 1997 - 16:06:41 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:37:16 MST