tmt@xpiinc.UUCP (Thomas M. Talpey) (12/14/88)
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
ron@ron.rutgers.edu (Ron Natalie) (12/15/88)
You DO NOT want to just use a timer to kill FIN-WAIT-2 state connections after some period of inactivity. This kills applications that legitimately work this way, notably rsh. It's been tried in the past. I tend towards the Phil Karn approach, that this should be left to the application. An application should decide how long after it closes the transmit side of a connection it should wait before it gives up and forces the TCB to go away. If data arrives after that, it should get a RST, which is the proper action whenever data arrives for a connection that doesn't exist. Of course, I believe UNIX lacks the ability to do this properly in 4.3 (I don't know what Mike has done in 4.4 or has in mind for the future). A application probe call that throws packets at an already FIN-ed connection to see if it can awaken the other end, might be useful however. -Ron