Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!TOVE.UMD.EDU!sandy
From: sandy@TOVE.UMD.EDU (Sandy Murphy)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP/IP close connection TIME_WAIT ?
Message-ID: <8908291630.AA21776@tove.umd.edu>
Date: 29 Aug 89 16:30:05 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 34

Please (please,please) correct me if I am wrong in this.

If Host A is in the TIME_WAIT state, then A has:
	sent a FIN,
	received a FIN,
	received an ACK (of its FIN)
	and sent an ACK (of Host B's FIN).
Therefore, Host B must have:
	sent a FIN,
	received A's FIN,
	and sent an ACK (of A's FIN).
Host B may not have yet received the ACK of its FIN.  So Host B is in state Closing
or LAST_ACK (if it hasn't received the ACK).  Host B has already passed
all of A's data up to the user.  But B doesn't know if A has sent all of B's
data to the user.  The TIME_WAIT state is to ensure that B can get an ACK
so it knows all the data was delivered (see page 22 of the specs).

	Actually, the TIME_WAIT state is not long enough to ENSURE this.  If 
A's ACK of B's FIN gets lost, B will retransmit its FIN (at least).  If this gets lost
as well, it is possible for the 2MSL timer to expire before B retransmits again and
the FIN arrives at A.  Chances are B will receive a RST in that case, because A
is CLOSED when the FIN arrives.

	Note also that both sides of the connection do not necessarily go 
through the TIME_WAIT state.  If Host A closes after it has received a FIN,
then it can send a FIN,ACK.  An ACK of this FIN means that Host B received
the ACK he needs, and A can go directly to CLOSED.

	In this sequence (ESTAB -> CLOSE_WAIT -> LAST_ACK -> CLOSED)
the specs don't say to send an ACK.  I'm just supposing that the FIN segment it
says to send should include an ACK.  Right?

--Sandy Murphy
  University of Maryland