Re: hierarchy problems

Gergely Madarasz wrote:

> I'm now using connect_timeout (10 sec), but I guess this affect both the
> peer connections and direct connections, right?

Right, and is why I have extended Squid with peer connect timeout
settings (both a global, and per peer settings).

> then I can't reach the parent which is on that link, and I can't reach
> the remote host directly either, though I could reach it thru the other
> parent. But squid would fail in 50% of the cases, because it would first
> try to connect to the failed parent, then directly, and work in the other
> cases by connecting to the working parent.

This is a bug. Sorry I forgot about this one when I wrote my first
message. I have a patch for it. Squid is supposed to declare the peer
dead when 10 connections have failed, but the counter isn't maintained
on connect_timeout. See below for patch info.

> > You shouldn't need to use ICP it it is only for monitoring if the peer
> > is alive. TCP connections does that job just fine.
>
> So if ICP is disabled, and several TCP connections fail, will my proxy
> mark the peer as dead, and use only the other?

When Squid is performing the way it is intended yes.

Patches of mine I'd recommend you to apply (in this order, or with
--fuzz=3, in which case the icp_dead_detection patch can be skipped if
so wanted):
 squid-2.2.DEVEL3.icp_dead_detection.patch
 squid-2.2.STABLE3.tcp_dead_detection_and_retry.patch
 squid-2.2.STABLE2.peer_connect_timeout-2.patch

> How will it detect when the dead peer comes back?

It will probe the dead peer with TCP connections until it answers again.

> So should I try that script wizardry for defaultroutes along with the
> peer connection timeout patch ? No routing protocol can be used, there are
> no isp-independent ip adresses :(

Might be a good idea. Doing so would allow you to reach hosts directly
if both the main link and the other peer is down at the same time.

--
Henrik Nordstrom
Squid hacker