NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/protocol/tcpip/5906

Text File | 1993-01-10 | 1.9 KB | 36 lines

Newsgroups: comp.protocols.tcp-ip
Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!think.com!ames!purdue!mentor.cc.purdue.edu!dls
From: [e-mail] (David L Stevens)
Subject: Re: time outs in FIN-WAIT2??
Message-ID: <[e-mail]>
Organization: PUCC UNIX Group
References: <[e-mail]> <[e-mail]>
Date: Mon, 11 Jan 1993 02:25:32 GMT
Lines: 25

In article <[e-mail]>, [e-mail] (Duncan McEwan) writes:
....
> It claims this is done as a work around because "certain other TCP
> implementations (incorrectly) fail to send a FIN on a receive-only connection.
> Connections to such hosts will remain in FIN_WAIT_2 state forever unless the
> system times them out".

    It's actually worse than that, in that it doesn't require a non-
conforming TCP to break things. When you're in FIN_WAIT_2, all data you've
sent has been acknowledged and the user has already done a close(). All
you're waiting for is the FIN from the other side. If the other machine
crashes, there isn't anything to cause you to delete the entry or ever
resend another packet, so the TCB will hang around forever.
    In old 4.2 BSD implementations, these used to collect until a reboot
was required to get back the resources they were holding. Adding the timer
prevents that, but has its own problems. Having a timer, but a long one,
is a compromise. Our Berkeley derivatives timeout after 30 minutes, which
is probably long enough; the #define is still named "TCPT_2MSL" (RFC 793
says 2MSL'd be 4 minutes).
    If I remember right, the original poster said 10 seconds-- a good
implementation will restart the TIME_WAIT timer each time it receives a
segment, so it really is timing the "dead interval" when the other side may
have crashed. Fixing that (or asking the vendor to) may be the solution.
--
                    +-DLS  ([e-mail])