On Tue, 8 Feb 2005, Paul Dugas wrote:
On some networks, yes. That may be the issue here. I may just need to just wait. Boy, how I wish it was standard to hand out http_proxy info in DHCP responses.
Well.. it is, sortof. See WPAD. Not an official standard but is supported by Microsoft (DHCP then DNS) and a few other browsers (only DNS, due to lack of integrated DHCP stacks outside of Windows...)
I guess I need to do some digging to get up to speed on how peers are deemed DEAD and how they;re restored, if ever.
A non-ICP peer is defined as dead if 10 consequtive TCP connections to the peer fails.
Once found dead Squid starts to probe them with TCP connrections when there is requests to be forwarded.
In addition the never_direct flag is a key component in a setup like yours. Without it Squid only selects a single peer and uses direct as fallback mechanism if the request could not be forwarded via the selected peer. If never_direct then all parents are selected as viable forwarding paths and Squid cycles over them until one is found working.
The order Squid selects the peers is dependent on which flags besides no-query is used. If no flags is used the peers is selected in the order listed in squid.conf.
How Squid selects which peer to use:
never_direct allow:
1. Selected ICP peer
2. The preferred parent
2a) default
2b) round-robin
2c) first alive parent found in squid.conf
3. all parents in the order listed in squid.confnever_direct deny (default):
1. Selected ICP peer
2. Direct if prefer_direct on
3. The preferred parent
4. Direct if prefer_direct offAlso notice that prefer_direct does not force Squid to use a parent, it is just a weak modifier to hint to Squid that it may be a good idea to use a parent on cacheable requests even if none responded to ICP.
If combined with nonhierarchical_direct then Squid is more willing to use a parent, but still only one single attempt to us a parent per request.
To make Squid really try to use the parents never_direct is needed as can be seen in the lists above.
Regards Henrik
