At 08:36 09/08/96 +0100, Andrew Cormack wrote:
>In this case the server is supposed to be running a cache, but isn't. I
>haven't been able to find out whether the cache program has been stopped
>for development purposes or has broken. The problem is that squid's check
>for aliveness (against a Netscape cache) only checks that UDP on the
>machine is alive, not the cache software. Since the inactive parent always
>responds fastest, squid is helpless until I manually remove the offending
>parent from the tables. A couple of possible solutions come to mind (there
>are no doubt others):
>
>1) Check aliveness of the cache s/w, not the machine (does the Netscape
> cache make any visible difference to the machine it runs on?)
Which is why better caches use 3130 as the UDP ping port, which is responded
to by the cache, not the UDP layer. Complain to Netscape if they don't do
this, although I thought I recalled that they do.
>2) Squid could perhaps record the fact that a host is returning 'connection
> refused' on it's supposed cache service port, and not use the parent
> again until some timeout expires. The individual request which
> detected the problems could either be failed, or re-processed with the
> modified list of parents.
For the time being install it as a neighbor, not a parent. If neighbors go
down, then squid detects it and doesn't use it. Unless you are behind a
firewall of course.
Jonathan L.
Origin UK, 323 Cambridge Science Park, Cambridge, England. CB4 4WG.
Tel: +44 (1223) 423355 Fax: +44 (1223) 420724 E-mail: guess...
-------[ Do not think that every sad-eyed woman has loved and lost... ]------
-----------------------[ she may have got him. -Anon ]-----------------------
These opinions are all my own fault.
Received on Fri Aug 09 1996 - 08:12:50 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:32:46 MST