Re: (104) Connection reset by peer

From: Michael Samuel <>
Date: Sat, 14 Feb 1998 08:45:06 +1100 (EST)

Ahh... I didn't read the subject line properly :-)

If a server accepts a connection, it should follow through with the
connection and reject others if it can't handle the load. If it is
dropping the connection while you're in the middle of a transfer, there is
little you can do about it, except trick squid into not caching the error
message. (Squid does cache failed connections for a small amount of time,
doesn't it?)

On Fri, 13 Feb 1998, Michael Pelletier wrote:

> Date: Fri, 13 Feb 1998 09:00:02 -0500 (EST)
> From: Michael Pelletier <>
> To: Apiset Tananchai <>
> Cc: Michael Samuel <>,
> Squid Users <>
> Subject: Re: (104) Connection reset by peer
> On Fri, 13 Feb 1998, Apiset Tananchai wrote:
> >
> > I already apply that patch to my squid server but the problem still occur
> > (approximately once a minute). If I remember correctly, Michael Pelletier
> > used to told me that the connection-retry patch has nothing to do after
> > the connection to www server established so it would not solve my problem.
> > I want something that will retry connection that get "Connection reset by
> > peer" error a few times befor give up.
> 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().
> 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.
> -Mike Pelletier.

Michael Samuel,

Surf-Net City - Internet Cafe and Internet Service Providers
Phone: +61 3 9593-9977
E-Mail: <>
Received on Fri Feb 13 1998 - 14:34:49 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:38:53 MST