II.5: How do I properly close a socket?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This question is usually asked by people who try close(), because they
have seen that that is what they are supposed to do, and then run netstat
and see that their socket is still active. Yes, close() is the correct
method. To read about the TIME_WAIT state, and why it is important,
refer to Part II, question 7.
II.7. Please explain the TIME_WAIT state.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Remember that TCP guarantees all data transmitted will be delivered, if at
all possible. When you close a socket, the server goes into a TIME_WAIT
state, just to be really really sure that all the data has gone through.
When a socket is closed, both sides agree by sending messages to each
other that they will send no more data. This, it seemed to me was good
enough, and after the handshaking is done, the socket should be closed.
The problem is two-fold. First, there is no way to be sure that the last
ack was communicated successfully. Second, there may be "wandering
duplicates" left on the net that must be dealt with if they are delivered.
Andrew Gierth (andrewg@microlise.co.uk) helped to explain the closing
sequence in the following usenet posting:
> Assume that a connection is in ESTABLISHED state, and the client is about
> to do an orderly release. The client's sequence no. is Sc, and the server's
> is Ss. The pipe is empty in both directions.
>
> Client Server
> ====== ======
> ESTABLISHED ESTABLISHED
> (client closes)
> ESTABLISHED ESTABLISHED
> <CTL=FIN+ACK><SEQ=Sc><ACK=Ss> ------->>
> FIN_WAIT_1
> <<-------- <CTL=ACK><SEQ=Ss><ACK=Sc+1>
> FIN_WAIT_2 CLOSE_WAIT
> <<-------- <CTL=FIN+ACK><SEQ=Ss><ACK=Sc+1> (server closes)
> LAST_ACK
> <CTL=ACK>,<SEQ=Sc+1><ACK=Ss+1> ------->>
> TIME_WAIT CLOSED
> (2*msl elapses...)
> CLOSED
>
> Note: the +1 on the sequence numbers is because the FIN counts as one byte
> of data. (The above diagram is equivalent to fig. 13 from RFC 793).
>
> Now consider what happens if the last of those packets is dropped in the
> network. The client has done with the connection; it has no more data or
> control info to send, and never will have. But the server does not know
> whether the client received all the data correctly; that's what the last
> ACK segment is for. Now the server may or may not *care* whether the
> client got the data, but that is not an issue for TCP; TCP is a reliable
> protocol, and *must* distinguish between an orderly connection _close_
> where all data is transferred, and a connection _abort_ where data may
> or may not have been lost.
>
> So, if that last packet is dropped, the server will retransmit it (it is,
> after all, an unacknowledged segment) and will expect to see a suitable
> ACK segment in reply. If the client went straight to CLOSED, the only
> possible response to that retransmit would be a RST, which would indicate
> to the server that data had been lost, when in fact it had not been.
>
> (Bear in mind that the server's FIN segment may, additionally, contain
> data.)
>
> DISCLAIMER: This is my interpretation of the RFCs (I have read all the
> TCP-related ones I could find), but I have not attempted to examine
> implementation source code or trace actual connections in order to
> verify it. I am satisfied that the logic is correct, though.
The second issue was addressed by Richard Stevens (rstevens@noao.edu,
author of Unix Network Programming). I have put together quotes from some
of his postings and email which explain this. I have brought together
paragraphs from different postings, and have made as few changes as
possible.
> If the duration of the T_W state were just to handle TCP's full-duplex
> close, then the time would be much smaller, and it would be some function
> of the current RTO (retransmission timeout), not the MSL (the packet
> lifetime).
> A couple of points about the T_W state.
>
> - The end that sends the first FIN goes into the T_W state, because that
> is the end that sends the final ACK. If the other end's FIN is lost, or
> if the final ACK is lost, having the end that sends the first FIN
> maintain state about the connection guarantees that it has enough
> information to retransmit the final ACK.
>
> - Realize that TCP sequence numbers wrap around after 2**32 bytes have been
> transferred. Assume a connection between A.1500 (host A, port 1500) and
> B.2000. During the connection one segment is lost and
> retransmitted. But the segment is not really lost, it is held by
> some intermediate router and then re-injected into the network. (This
> is called a "wandering duplicate".) But in the time between the
> packet being lost & retransmitted, and then reappearing, the
> connection is closed (without any problems) and then another
> connection is established between the same host, same port (that is,
> A.1500 and B.2000; this is called another "incarnation" of the
> connection). But the sequence numbers chosen for the new incarnation
> just happen to overlap with the sequence number of the wandering
> duplicate that is about to reappear. (This is indeed possible, given
> the way sequence numbers are chosen for TCP connections.) Bingo, you
> are about to deliver the data from the wandering duplicate (the
> previous incarnation of the connection) to the new incarnation of the
> connection. To avoid this, you do not allow the same incarnation of
> the connection to be reestablished until the T_W state terminates.
>
> Even the T_W state doesn't complete solve the second problem, given
> what is called T_W assassination. RFC 1337 has more details.
>
> - The reason that the duration of the T_W state is 2*MSL is that the
> maximum amount of time a packet can wander around a network is
> assumed to be MSL seconds. The factor of 2 is for the round-trip.
> The recommended value for MSL is 120 seconds, but Berkeley-derived
> implementations normally use 30 seconds instead. This means a T_W
> delay between 1 and 4 minutes. Solaris 2.x does indeed use the
> recommended MSL of 120 seconds.
> A wandering duplicate is a packet that appeared to be lost and was
> retransmitted. But it wasn't really lost ... some router had problems,
> held on to the packet for a while (order of seconds, could be a minute
> if the TTL is large enough) and then re-injects the packet back into
> the network. But by the time it reappears, the application that sent
> it originally has already retransmitted the data contained in that packet.
> Because of these potential problems with T_W assassinations, one should
> *not* avoid the T_W state by setting the SO_LINGER option to send an
> RST instead of the normal TCP connection termination (FIN/ACK/FIN/ACK).
> The T_W state is there for a reason; it's your friend and it's there to
> help you :-)
> I have a long discussion of just this topic in my just-released "TCP/IP
> Illustrated, Volume 3". The T_W state is indeed, one of the most
> misunderstood features of TCP.
> I'm currently rewriting UNP and will include lots more on this topic, as
> it is often confusing and misunderstood.
