questions about timeouts and lifetimes in squid-1.0.18

From: Joe Ramey <ramey@dont-contact.us>
Date: Fri, 25 Oct 1996 14:43:51 -0500

In looking at my file descriptor exhaustion problem, I've been looking
at how our file descriptors are actually used. I'm wondering about
how the timeouts get set up. In particular, I am wondering about two
classes of file descriptors in which the lifetime has been set but not
the timeout. This is in squid-1.0.18.

A few examples of the first class:

                ( 33 = 7038, 0) NET 172.25.50.58 GET http://www.osf.org/mall/web/JDK/1.0.2/os
                ( 45 = 106, 0) NET http://www.zdnet.com/anchordesk/images/getfree.gif
                ( 50 = 8409, 0) NET 172.25.20.28 GET http://www.jasc.com/ornsw.zip
                ( 63 = 114, 0) NET http://www.attorneyplacement.com/areas.htm
                ( 64 = 119, 0) NET http://home.netscape.com/home/internet-search.html

Here, the lifetime is decreasing, and soon these will be killed, but
there's apparently no timeout yet. Why is that? Is the ReadTimeout
only set after at least one read from the server has occurred?

Here are some examples of the second type:

                ( 35 = 67, 0) NET 156.117.67.89
                ( 38 = 1329, 0) NET 172.25.10.27
                ( 68 = 1022, 0) NET 172.25.10.27
                ( 83 = 9975, 0) NET 192.91.94.35
                ( 91 = 2015, 0) NET 172.25.10.27

Now, I understand that the only timeout on the client side is a
lifetime timeout, is that correct? Normally this is okay because the
other end of the connection, the file descriptor associated with the
upstream web or ftp server, will have a read timeout associated with
it, so if the connection hangs it will time out on the reading end
(and then we'll send the client a timeout). But what if the client
connects but never sends a command? Will we wait for the entire
client lifetime timeout (default of 200 minutes) before we disconnect
them?

Joe
Received on Fri Oct 25 1996 - 12:45:09 MDT

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