Re: Feature request

On 01 Nov 2002 20:19:44 +1100
Robert Collins <robertc@squid-cache.org> wrote:

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

Right (that it is tunable, and DirecWay doesn't appear to set it). And some versions of Windows ignore the setting, letting the backlog go no higher than 5. Yuck. We experience this at work with tomcat running on a Windows NT Workstation machine. No matter what value we give the backlog count it doesn't seem to take and we finally read on the Microsoft Developer Network docs that the max is 5 on NT Workstation. That isn't true of NT Server and W2K.

> Have you considered running squid on the Windows machine?

Yes. However the Windows machine I have is a fairly small machine (very little hard drive space left and such). The only reason I really have it is DirecWay only runs on Windows. DirecWay, BTW, is a two-way satellite internet connection for those of us that live in areas that have other alternative to getting high speed internet access. My only other option where I live is 28.8K dialup. There are actually some projects going on to make it work under Linux but it isn't there yet.

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

That'd be fine.

> > 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?

Agreed - it isn't nice. The only reason for the delay is the repeated retry without the delay uses a little more CPU than it really should. It otherwise isn't necessarily needed. One nice thing about the delay is it makes it such that if you set the retry attempts it really becomes # of milliseconds to retry, which is good because then the retry attempts needed won't rely on the speed of the machine running squid. So if I move up to a faster machine I shouldn't have to double the retry attempts. I'm not married to the idea though. After all, for my particular situation it normally doesn't need to retry more than about 20 milliseconds.

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

Sounds great. I'll either not do the delay at all, or will leverage eventAdd.

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

Sounds good. I'll see if I can find a little time over the next week or two.

Thanks!
Ray Cole
Received on Fri Nov 01 2002 - 09:20:54 MST