Date: Fri, 22 May 1998 16:27:13 -0400 From: sbabkin@dcn.att.com To: mark@vmunix.com Cc: hackers@FreeBSD.ORG Subject: RE: TIME_WAIT/FIN_WAIT_2... Message-ID: <C50B6FBA632FD111AF0F0000C0AD71EEACDF64@dcn71.dcn.att.com>
next in thread | raw e-mail | index | archive | help
> ---------- > From: Mark Mayo[SMTP:mark@vmunix.com] > Sent: Friday, May 22, 1998 1:54 PM > To: Jim Shankland; tlambert@primenet.com > Cc: hackers@FreeBSD.ORG; isp@FreeBSD.ORG > Subject: Re: TIME_WAIT/FIN_WAIT_2... > > On Fri, May 22, 1998 at 09:43:04AM -0700, Jim Shankland wrote: > > > So what you're really seeing, Mark, is connections in FIN_WAIT_2 > state, > > where the web server has closed the socket, but the client has never > > indicated that it is done sending. These hang around for about 11 > > minutes, then disappear. (Of course, more take their place.) > > > > The reason for the 11 minute wait is so that if the client is just > > slow going through its shutdown stuff, the server can still walk the > > client through an orderly close. On the other hand, maybe 11 > minutes > > is too long? I'll bet nothing terrible happens if that timeout > drops > > to 1 minute ... or 30 seconds. Even 0 would at worst lead to some > > unnecessary RST's on closing connections. Anyone have any thoughts > on > > this? > > I'm thinking that setting it to 2MSL, like TIME_WAIT might be okay, > and still relatively conservative. 4 minutes is not bad, and on a > It occurred that I'm reading the McKusick & other's book right now and this is the exact quote on the TCP implementation: "In addition, 4.4BSD starts the 2MSL timer when FIN_WAIT_2 state is entered after the user has closed." So, probably this is the reason why you don't see so many hanging sockets in FIN_WAIT_2 on FreeBSD. -Serge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C50B6FBA632FD111AF0F0000C0AD71EEACDF64>