Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!xpiinc.UUCP!tmt
From: tmt@xpiinc.UUCP (Thomas M. Talpey)
Newsgroups: comp.protocols.tcp-ip
Subject: TCP implementations and FIN-WAIT-2
Message-ID: <8812131807.AA06763@felix.xpiinc.uu.net>
Date: 13 Dec 88 18:07:25 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 19

I have a question regarding others' approach to the following TCP
implementation problem. When a TCP closes its connection in the outgoing
direction and its FIN is acked, it enters state FIN-WAIT-2 and continues
to accept segments from the remote TCP. However, since it has indicated
FIN, it can send no more data, and since its FIN is acked, its retransmit
timer is not ticking, therefore it has no way to probe the connection
for liveness. In fact, if the remote TCP has crashed it seems quite likely
the connection will remain forever.

My question is, in the absence of keepalives how can the local TCP ensure
that it does eventually delete its tcb? Possibly it can set a timer (and
retrigger it on each receive), resetting the connection if it expires, but
this seems precarious. Or perhaps it can send redundant window updates and
expect a RST, but if the other end has gone away completely these will
always "succeed". I know 4.3 sets a reasonably large timer but I also wonder
if there is any widely accepted "standard practice" to cover this problem?

Tom Talpey
Xpi Inc, division of Visual Technology
tmt@xpiinc.uu.net