Re: Feature request

On Fri, 2002-11-01 at 15:01, Ray Cole wrote:

Hi Ray...

> I have a request for a feature. Actually it is a feature I've
implemented inside of squid and I want to pass it on.

Cool. We like features :].

> I use squid on my Linux box to assist in communicating to a DirecWay
proxy server that resides on my Windows machine. It works great, except
for a little problem with Windoze. I tend to get a large number of
'connection refused' errors when connecting to the proxy on my Windoze
machine. This is caused by the fact that Windoze doesn't allow much of
a backlog when listening for connections. I'm sure you're well aware of
these type of issues with Windoze.

Errm, actually that is fully tunable on Win32, just as it is on un*x.
Sounds like DirecWay aren't doing that though.

> Fortunately if the connect attempt is retried it tends to work, but
sometimes requires a bit of a delay. I'm aware that squid retries up to
10 times, but it doesn't put any delay in it. So if the machine running
the squid is considerably faster than its parent cache (which it is in
my situation) this immediate retry of 10 attempts isn't sufficient.

Have you considered running squid on the Windows machine?
 
> I made a modification to allow a new parent proxy configuration
option: retry-attempts=x, where x is the number of times to re-attempt a
connection to the cache. I modified cache_cf.c to support the new
command, structs.h to add a 'max_attempts' to the __peer structure, and
finally neighbors.c to use this max_attempts on tcp_up rather than
PEER_TCP_MAGIC_COUNT (10). 10 remains the default.

Cool. Are you interested in porting it to the current squid development
branch? Thats squid-3 by preference (which is C++ based).

> neighbors.c was also modified to add a usleep(2) after connection
failure to delay a very short time to allow time for the parent cache to
clear up. This delay only happens if the connection to the parent
failed because the connection was refused.

Hmm. This is bad, squid relies on non blocking behaviour. Why do you
need the delay?

> This makes squid very reliable and gets around the problems I was
having before. I realize the usleep() in neighbors.c itself might not
be such a great thing, though it is a very small delay. I figure it
really belongs elsewhere to keep from blocking other requests. But for
my situation it works out fine. Prior to this modification squid would
believe the parent cache to be dead, causing it to go direct which is a
very, very bad thing when using DirecWay (where the parent proxy is
basically a must to obtain good performance).

What is DirecWay?
What you can do rather than a microsleep is register an event via
eventAdd. That allows non blocking behaviour, and a small delay as
needed.

> Anyway, I'd like to offer this as a request to add this feature to
squid in a future release. I'd be glad to send the changes I've made,
though this is obviously a very simple thing to implement. Certainly
this isn't a 'normal' condition, but perhaps it might be useful to some
others out there.
>
> My apologies if this is not the proper place to send this
information/request. I commend you for a fine job of creating a very
flexible caching proxy. It is truly remarkable.

This is absolutely the right place to send it. I for one would like to
see a tweaked version of this included in HEAD. The usual approach for
such mini projects is a small branch in the CVS repository at
http://devel.squid-cache.org/ (we allow anyone with a sourceforge user
account who wishes to become a developer write access here)..

Cheers,
Rob