Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!geof@decwrl.DEC.COM@apolling.UUCP
From: geof@decwrl.DEC.COM@apolling.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Problem with TCP state transitions in CLOSE
Message-ID: <8702171755.AA00052@apolling.imagen.uucp>
Date: Tue, 17-Feb-87 12:55:33 EST
Article-I.D.: apolling.8702171755.AA00052
Posted: Tue Feb 17 12:55:33 1987
Date-Received: Wed, 18-Feb-87 20:26:09 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: imagen!geof@decwrl.DEC.COM
Organization: The ARPA Internet
Lines: 37
Approved: tcp-ip@sri-nic.arpa


 > The TCP receives a data segment while in FIN-WAIT-2, just before receiving
 > the FIN.  Now, it's entirely likely that the application won't get around to
 > doing it's next RECEIVE (for what will be the last buffer of data sent over
 > from it's buddy on the other end) until the TCP has gotten the FIN.

The SYN & FIN bits are bytes of control that are IN the data stream.
They consume sequence numbers, and only have meaning when taken in
sequence.  The presence of a FIN at the TCP level may cause a state
to be changed or a flag to be set, but the connection can not actually
close until the application has tried to RECEIVE the FIN.

Thus, there are two aspects of TCP state, the state at the TCP level,
and the state as transmitted by TCP to its client level.  The TCP
connection transitions to TIME-WAIT when it receives a FIN that is
ready to be delivered to the client (note that last caveat, if the
last data packet was lost, the state transition must wait until all
the unRECEIVED data before the FIN is present).  But the TCP connection
does not tell its client that the connection is closed until the
client tries to RECEIVE the FIN.  In practise, this means that you
must maintain the connection state even after it has closed, to allow
the client to receive every last byte of data.

===aside========

While I have your ear, let me sound off about a pet peeve that you
can preemptively fix in your implementation.  The TCP layer should be
willing to remain in zero window state arbitrarily long, as long as
control packets are still crossing the connection.  Don't time out a
connection just because the window is zero for a while.

Last I checked, Apollo (SR 9.2.3), Tops-20, Unix 4.2 all exhibit this bug.

===edisa========

- Geof Cooper
  IMAGEN