Re: Peer/source selection

From: Dancer <dancer@dont-contact.us>
Date: Wed, 10 Jun 1998 00:36:25 +1000

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alex Rousskov wrote:
>
> 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.

Hmm, granted.

I _am_ in favour of named algorithms that can be arranged in a
squid.conf (say 'peer_selection cache-digest icp-hit any-parent
direct'). I also think we need a custom selector algorithm that the
administrator can write. For example, I've recently been asked to write
one that goes:

IF (client's IP address is currently in independently maintained list X)
AND
   (the URL begins with a string from the independently maintained list
Y) THEN
        (must request from parent1)
        ELSE
        (fetch from source)

..and another that goes..

IF (client's IP address is currently in independently maintained list X)
AND
   (the URL matches a regexp from the independently maintained list Y)
THEN
        (request directly)
        ELSE
                IF (object is currently cached) THEN
                        (return cached object)
                ELSE
                        (fail)

Lord knows, this isn't the only client asking for special bells,
whistles, gongs, chinese harmonicas, variations on peer-selection and
LRU. So my assumption is that there are probably more folks that want
stuff like this. :/

D

--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:49 MST