Re: Peer/source selection

From: Alex Rousskov <rousskov@dont-contact.us>
Date: Tue, 9 Jun 1998 08:09:42 -0600 (MDT)

--MimeMultipartBoundary
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 7 Jun 1998, Dancer wrote:

> To try to prevent duplication of effort (as happened recently) and to
> just float an idea that I'm considering, I'd like to get some comments
> on this. 'this' is a function to be called at the beginning of
> peer/source selection allowing the default behavior to be retained or
> radically subverted.

Yes, I think that having such a function may solve a few problems. Ideally,
however, we probably need a collection of such "functions" with the order
configurable from squid.conf. (We already have several peer selection
algorithms and a "user defined" algorithm should be just one of them).

There are two big problems with this approach that we have to solve.
First, if an algorithm, say "CacheDigest", tries to fetch an object and fails
(e.g. receives 504 reply from a peer), this should not prevent us from trying
some other algorithms (e.g. "UseAnyParent" or "GoDirect") based on the order
specified in squid.conf. The code that will allow us to do that is in works
now (but based on the current fixed-order scheme). When it is ready, a lot of
peering problems will be solved.

The second problem is changing current "if-then-else" structure to a set of
functions/algorithms, passing the info between the algorithms, and
controlling that the user defined order actually makes sense.

Since the first problem (which is far more complex, IMO) is being solved now,
I would wait for the new code to be released before trying to address the
second issue.

Thank you,

Alex.

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:51 MDT

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