Re: cache_peer_? setting for internal peer

Andrew S. Howell wrote:

> cache_peer imeproxy.tibco.com parent 8080 7 no-query no-digest no-netdb-exchange

...

> So it looks like its matching the regex, but then not selecting the
> proxy.
>
> Any ideas?

Squid is a bit picky about selecting parents for which it has nothing to
weight the selection on... You can get around this by using
never_direct.

The current peer selection algorithm is something like this (see
peerSelectFoo):

1. DIRECT if always_direct
2. If there is a single parent matching the request, and this parent has
no-query set then use this parent.
3. DIRECT if non-hierarchical and not matching never_direct.
4. Digest HIT peer.
5. CARP selected parent.
6. Closest parent according to netdb
7. ICP HIT selected parent.
8. DIRECT if we are closer than closest netdb peer.
9. ICP netdb closest MISS
10. ICP fastest MISS
11. DIRECT unless never_direct
12. Some available parent (default/roundrobin/firstup/anyup)
13. Fail

non-hierarcical requests is: (see clientHierarchical)

n1. IMS queries if some of the ICP peers are not supporting ICP Request
Numer field.
n2. Authenticated requests
n3. TRACE is always hierarchical.
n4. non GET request
n5. matching hierarchy_stoplist
n6. not cacheable

Problems:

2: single_parent before non-hierarchical check.
10/11: no way to have it prefer to use a parent if one is available and
DIRECT if no parents are available.
3: Some may want non-hierarchical requests to be processed as
hierarchical.. (mostly to get around economic rules which higher parties
are trying to enforce.. like UK/AU backbone/international traffic rate
policies)
5: What about CARP siblings? I think the current CARP implementation is
a bit confused about parent/sibling(array) relationships. Both are
perfectly legal. see the CARP draft specification (currently only
available from MS as previously released internet-draft has expired).
n3: TRACE should be regarded in the same way as a GET request. Doing a
forced hierarchical for TRACE makes the result unreliable.

All ACL checks in cache_peer_access has to be "fast"(non-blocking). I.e.
dst type ACLs are uncertain, and dstdom* are uncertain if the request
uses an IP address.

---
Henrik Nordstrom
Spare time Squid hacker