RE: Squid-1.1.20

Hi,

This retry patch seems like something I need, but, I've downloaded it
read the "retry-patch.doc" and still don't know what to do with it!!

Err, help?

Nik.

--
Nik Oxley - nik.oxley@iholland.co.uk
IT Administrator, I Holland Limited - http://www.iholland.co.uk/
	-----Original Message-----
	From:	Michael Pelletier [SMTP:mikep@comshare.com]
	Sent:	08 April 1998 14:16
	To:	Evaghelos Tsiotsios
	Cc:	squid-users@nlanr.net
	Subject:	Re: Squid-1.1.20
	On Wed, 8 Apr 1998, Evaghelos Tsiotsios wrote:
	> We have recently upgraded the Squid installation in our site
(80 hosts)
	> to 1.1.20. (Linux kernel 2.0.33).
	> There are a couple of things I' d like to ask, though. 
	Welcome to Squid!  :-)
	> I am noticing myself - and getting some complaints from
colleagues also-
	> that often enough we get read error messages and the
connection is
	> aborted. If the user insists (reload twice or three times)
then he/she
	> gets the page he wants. Also, at times, not the whole page is
downloaded
	> leaving some elements 'blank'. 
	This is the exact problem that led me to write the
connection-retry patch,
	available at <ftp://ftp.comshare.com/pub/squid/>.
	What's probably happening when the users are reloading two or
three times
	is that they are in effect "redialing" a busy server.  According
to the
	RFC, a server does not have to actually tell the client that it
is busy
	with a 5xx HTTP response, it can simply refuse connections.  The
effect of
	this is that it is hard to tell from connection to connection
whether a
	server has crashed or is just very busy.
	And since some hosts have multiple IP addresses, if one server
isn't
	responding, one or more of the others usually are, but Squid and
browsers
	don't know this and so give up on the first refused connection. 
	The retry patch will try single-address hosts up to three times
	(configurable), and will try every address of a multiple-address
host
	before returning an error to the Squid user.  And unless the
server is
	*extremely* busy or *really* crashed, it will almost eliminate
any
	appearance of problems at the end user's browser.  A side
benefit is that
	it routinely allows a 99+% ipcache hit rate, because it keeps
track of the
	state of addresses in the cache rather than just dumping the bad
ones.
	Now, if a server actually does return a 5xx error stating
explicitly that
	the server is too busy (which in my own experience is a fairly
rare
	event), the user will recieve that "too busy" message without
any retry
	attempts.  This case is more difficult to retry since it
involves parsing
	the text returning from the server and recreating a filehandle
much later
	in the connection process.  However, in this case the user is
explicitly
	told that the problem is at the remote server's end of the
connection, so
	they won't call *you* and whine about it. 
	Let me know if you have any questions about the patch.
		-Mike Pelletier.
	--
	Support the Astronaut Dollar Coin Initiative:
<http://home.rmi.net/~dcarr/dollar.htm>