--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Could you not rewrite plug-gw to do this job in a comparitively short
period?
Alex Rousskov wrote:
>
> On Sun, 31 May 1998, Eric Stern wrote:
>
> > CARP (Cache Array Routing Protocol) intelligently divides load
> > up between a number of proxy servers.
>
> Just to clarify:
>
> CARP divides the load absolutely un-intelligently. The redirection is based
> on a hash value of a URL. For _example_, URLs with MD5 in the first 30% of
> MD5 range [0, 0.30*2^128] go to proxy1, next 50% go to proxy2, and last 20%
> [0.80*2^128, 2^128] go to proxy3.
>
> In general, CARP redirector knows nothing about the popularity (frequency of
> accesses) of URLs and _actual_ load on the proxies. Thus, CARP does not do
> "smart" load balancing, resource allocation and access control, and such. If
> the load on individual proxies changes asynchronously OR if you guessed the
> "carp-load-factor"s wrong, CARP may overload one proxy while the other will
> be under-loaded.
>
> However, as most simple but general ideas, CARP is a very good solution for
> dividing a stream of requests between proxies when both
> - capabilities of proxies are stable and known a priory
> (these capabilities are reflected in the carp-load-factor in the
> patch),
> - load variation on each of the proxies is synchronized
> or negligible.
>
> A few questions about the patch:
>
> After quick checking, I failed to find any modifications to
> cf.data.pre in the patch. Please consider moving your notes in README.CARP to
> that file.
>
> In README.CARP you use "carp-load-factor". The parser checks for
> "carp_load_factor". Also, the last parameter of strncasecmp() looks strange.
>
> Can we use MD5s instead of computing hash values from scratch?
Tricky. MD5 is under ITAR export/import control. You have it, and we
have it. But the USA and Canadian governments forbid us giving
each-other additional copies. @whee. Despite the growing air of
religious freedom in encryption circles, I would think carefully before
including any of the MD hash sequences, much as they remain distinct in
the Apache distributions. (or at least they used to. Not sure on the
current state of art)
> This
> would (a) eliminate quite expensive loop through each character of a url, (b)
> improve distribution of hash values (sum of characters with a shift is not a
> good hashing function). Does CARP specs fix the method of computing that hash
> value?
>
> Current implementation uses CARP to select among siblings and no
> parents or non-carp siblings are allowed in squid.conf. The idea, as I
> understand it, is to use CARP-enabled Squid as a CARP redirector only rather
> than a caching proxy. I am not sure, but it seems to me that using CARP for
> selecting parents makes sense as well. That is, CARP could be used in a more
> general form in a _caching_ proxy, similar to the round-robin option... What
> do you think?
>
> Thanks for the patch!
>
> Alex.
>
> > from the CARP White Paper (Copyright Microsoft Corp.)
> >
> > CARP uses hash-based routing
> > to provide a deterministic "request resolution path" through an array of
> > proxies.
> > ...
> > 1) Because CARP provides a deterministic request resolution path, there
> > is none of the query messaging between proxy servers.
> > ...
-- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GAT d- s++: a C++++$ UL++++B+++S+++C++H++U++V+++$ P+++$ L+++ E- W+++(--)$ N++ w++$>--- t+ 5++ X+() R+ tv b++++ DI+++ e- h-@ ------END GEEK CODE BLOCK------ --MimeMultipartBoundary--Received on Tue Jul 29 2003 - 13:15:50 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:48 MST