Re: (104) Connection reset by peer

On Fri, 13 Feb 1998, Michael Pelletier wrote:

> Yes, that's correct -- the retry patch will only retry
> connection-establishment problems, such as when a server is down or busy,
> and it works best when the site has several IP addresses, such as
> Microsoft.
>
> Apiset's error occurs after the connection is established, which a few
> layers out from the retrying that the retry patch does within the
> commConnectHandle() routine, which is within commConnectStart(), within
> httpConnect(), which is a *handler* within ipcache_nbgethostbyname()
> within the httpStart(), ftpStart(), gopherStart(), etc. routines called
> from a switch in protoStart().

It's far too complex than I ever though while I was trying to see where
should I start first.. :)

> You begin to see the reason I implemented the retry in commConnectHandle()
> -- that was the place to do it while making the absolute least change in
> the code. Retrying connections that are already established, but have
> closed unexpectedly, is, from what I can tell, a bit more complex due to
> the handler-based pseudo-multi-threaded architecture of Squid. I'll dig
> into it a bit more and see what I can come up with, perhaps I'm just not
> conversant enough with the nuances of the use of Squid's handlers to see
> an obvious solution.
>
> And I suppose another question is whether automatically retrying
> established-but-dropped connections is a good idea in general. At first
> glance that would seem to tangle with a few other areas, such as dealing
> with the partially-retrieved cache object correctly.

I just got another idea, please comment on it if it would work or not. As
I mention in my previous post I'd like to retry on "Connection reset by
peer" connection only so wouldn't it more simpler if I just return
something to tell the client to try again, eg. something like:

<meta http-equiv="refresh" content="1; url=http://bla.bla.bal">

when I got ECONNRESET instead of return error page saying that there was
an error reading that page? since if the connection is really down you
shouldn't get a read error and ECONNRESET next time you try to connect to
the same page.

It may look a bit ugly and very inefficient but I think it should work..
I haven't try yet, maybe I will try to implement this and see how it work.
BTW, I have to wait until 1am when no much user using my proxy. :)

Above error is one major reason why I can not convince my boss to let me
implement transparent proxy using Cisco route-map + squid. ;-)

Thanks for your help,

--
aet