Feature request

Hello.

My name is Ray Cole. I've been using squid for about a year, using Linux for several years now and am a 'software architect' for a fairly large software company. C/C++ is my language of choice (JAVA is not a language...it is a glorified scripting language ;-) Anyway, enough with an introduction - it could only bore you....

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.

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.

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.

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.

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.

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).

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.

-- Ray
Received on Fri Nov 01 2002 - 02:06:57 MST