Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!mace.cc.purdue.edu!dls
From: dls@mace.cc.purdue.edu (David L Stevens)
Newsgroups: comp.bugs.4bsd
Subject: Re: TIME_WAIT sockets clog system
Keywords: ftp mbufs mget mput time_wait
Message-ID: <2654@mace.cc.purdue.edu>
Date: 4 Jul 89 14:35:18 GMT
References: <33437@wlbr.IMSD.CONTEL.COM>
Organization: PUCC UNIX Group
Lines: 24

In article <33437@wlbr.IMSD.CONTEL.COM>, sms@wlv.imsd.contel.com (Steven M. Schultz) writes:
> 	it would be enlightening to know why sockets stay around so long
> 	in a TIME_WAIT state (especially on a LAN) and what would break
> 	if the timeout interval were reduced.

	Since TCP works on top of IP, in theory, anyway, it can't tell the
difference between a LAN and a 5-hop internet connection. The timeout is
(perhaps unfortunately) fixed at 2*(Maximum Segment Lifetime) with no
assumptions about the connection.
	One bad thing that can happen if you timeout too fast is that, if
the ACK to the remote guy's FIN is dropped, you won't be there to ACK his
retransmission and he'll be stuck in LAST_ACK. On pre-tahoe (maybe pre-4.3--
too many distributions!) systems, that wait is forever; current BSD code
times out of LAST_ACK. Non BSD, RFC-793 conforming code will still wait
forever.
	Another way of handling this is to free all of the resources except
a stub PCB with just the basic info. Pretty much the only function of a
TIME_WAIT state endpoint is to re-ACK retransmitted FINs.
	Yet another way, not to TCP spec but in the right spirit, is to
make the TIME_WAIT interval a function of the srt. On fast connections,
it'd go away quicker. 2*MSL is the absolute worst case, which probably
never happens.
-- 
					+-DLS  (dls@mace.cc.purdue.edu)