Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!ENGVAX.UUCP!KVC
From: KVC@ENGVAX.UUCP.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Problem with TCP state transitions in CLOSE
Message-ID: <8702170259.AA25812@ucbvax.Berkeley.EDU>
Date: Mon, 16-Feb-87 20:58:00 EST
Article-I.D.: ucbvax.8702170259.AA25812
Posted: Mon Feb 16 20:58:00 1987
Date-Received: Tue, 17-Feb-87 18:39:45 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 68
Approved: tcp-ip@sri-nic.arpa

I'm having a problem with an implementation detail of a TCP/IP and I hope
I can get some insights from those who've gone before.
 
The situation is as follows:
 
According to RFC 793, a CLOSE operation means "I have no more data to send."
"The user who CLOSEs may continue to RECEIVE until he is told that the
other side has CLOSED also."
 
Now, my client application does a CLOSE, the TCP sends a FIN and goes from
ESTABLISHED to FIN-WAIT-1.  When the FIN is ACKed, it goes from FIN-WAIT-1
to FIN-WAIT-2.  While in FIN-WAIT-1 or FIN-WAIT-2, data continues to be
received from the network and the application may continue to issue RECEIVEs
to get the data.  Finally, the other end of the connection does a CLOSE
and the TCP receives a FIN.  Receiving a FIN in FIN-WAIT-2 means transition
to TIME-WAIT.
 
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.
(Not only is this likely, it happens most of the time, depending on
system response time, to an application here.)
 
The question is, what is a TCP to do if it is in FIN-WAIT-2, it has some
user data that the user hasn't asked for yet, and a FIN comes in?  If it
goes immediately to TIME-WAIT (as this TCP does) the user will receive an error
because RFC 793 says that a RECEIVE call while in TIME-WAIT returns "error:
connection closing."  Seems to me that what we would like to be in here
is a state similar to CLOSE-WAIT, in that RECEIVEs are allowed, but "must
be satisfied by text already on hand, but not yet delivered to the user."
 
There are two possible work-arounds that I came up with, though I am not
particularly happy with them and will wait for some cogent feedback before
implementing.
 
1) Go to TIME-WAIT as the spec says, but handle a user RECEIVE call as described
   in CLOSE-WAIT.
2) If there is user data outstanding when you get a FIN in FIN-WAIT-2, delay
   the transition to TIME-WAIT until the user data has been delivered to
   the user (i.e. he came and asked for it all).
 
My problems with 1) are that you aren't really following what the spec says
and that I'm not sure what to do if that user data is still there after
the 2 MSL timeout has passed.  I don't think it's right for the data to
go away after 2 MSL, since then the success  of the application is dependent
on how fast it can RECEIVE, and I don't think the TCP is supposed to introduce
restrictions like that.  (Please tell me if I'm off base here!)
 
Maybe 2) is better?  Seems to me, though, that the state transition isn't
really handled as the spec says. Also, are you getting out of synch by
staying in FIN-WAIT-2 when everyone expects you to have moved onto TIME-WAIT?
If so, does anyone care?
 
Why did RFC 793 specifically describe what to do with user data in CLOSE-WAIT
but not in this case?
 
How have others handled this in their implementations?  I tried to look
through the Berkeley 4.3 code, but found it a little murky.  I decided they
didn't do (2) but am not sure exactly what voodoo they do do.
 
Thanks for any info,
 
        /Kevin Carosso              kvc%engvax.uucp@usc-oberon.usc.edu
         Hughes Aircraft Co.
 
ps.  If anyone cares, it's the CMU rewrite of the Tektronix IP/TCP code
     for VAX/VMS.