Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!UCBVAX.BERKELEY.EDU!karels%okeeffe
From: karels%okeeffe@UCBVAX.BERKELEY.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Problem with TCP state transitions in CLOSE
Message-ID: <8702180422.AA04555@okeeffe.Berkeley.EDU>
Date: Tue, 17-Feb-87 23:22:16 EST
Article-I.D.: okeeffe.8702180422.AA04555
Posted: Tue Feb 17 23:22:16 1987
Date-Received: Wed, 18-Feb-87 22:53:21 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 22
Approved: tcp-ip@sri-nic.arpa

As there was some question as to how 4.2/4.3 handle the receipt of a FIN
with unreceived data, I'll answer that question.  The buffering of received
data and synchronization with the user programs is handled in the (generic)
socket layer in 4BSD.  As data is received and ordered by the TCP,
it is handed to the socket layer to await a receive call.  When a FIN
is received (and all data preceding it), TCP processes the FIN and enters
TIME_WAIT state.  The user process may consume the data at its leisure,
and is notified of the end of data (FIN) after the preceding data is consumed.

		Mike

aside to Geof Cooper re: zero windows:
===aside========

The bug to which you alluded, failure to tolerate persistance of a zero
window, does not occur in 4.2 as you describe it.  4.2 becomes impatient
and closes only if the zero window results from shrinking a window
into which it has already sent data.  It will also reset a connection
when new data is received, but cannot be accepted because the user
process has closed and exited without waiting for the connection to close.

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