CS558 Sylabus TCP: terminating a connection Terminating a TCP connection Closing a TCP connection is a much easiest than establishing a TCP connection (it is usually easier to destroy than to build....) The process is very much like ordinary data transfer - with the last ACK step "dangling" Properties of the disconnect operation: Symmetric Independent The TCP disconnect operation is symmetric In other words: Both the client and server can initiate the disconnect operation. (The connection request is always initialized by the client) The TCP disconnect operation is independent In other words: It is possible for one side to close its TCP connection without having the other end of the connection to be closed... The remaining TCP connection is a uni-directional connection Effect of closing a TCP connection: The TCP module that closes its TCP connection will no longer be able to transmit The TCP module that has closed its TCP connection can still continue to receive data from the other end !!! (Recall that a TCP connection is uni-directional) Programming note: The socket application programming interface (API) do not support a one-sided close operation.... In a TCP socket, when one end of the TCP socket is closed, the other end of the TCP socket is closes by the API automatically. The Transport Layer Interface (TLI) from AT&T does support one sided closing of a TCP end point... The function t_sndrel(int fd) will release the send capability of the TCP end. Message exchanges in the disconnection operation of TCP TCP close is also known as disconnect The messages exchanged in the TCP disconnection protocol when the client closes its connection --- is as follows: Client sends a FIN request: The FIN message (the FIN bit in the TCP header is set) is used to disconnect a TCP connection Server acknowledges the client's FIN request: When the server TCP module received the FIN request, it does: Send an ACK reply to the sender Invalid the ACK number Client processes the ACK reply: When the sender of the FIN request received the ACK reply, it invalidates its sequence number (Now the client cannot send message because its sequence number is invalid) Note: The reverse TCP connection is not closed: The server has a valid sequence number !!! We say that the TCP connection "half close". (In the text book (if you bought one), the TCP state after closing one direction corresponds to the FIN_WAIT_2 state It is not the CLOSED state --- in the CLOSED state, both TCP connections are closed). While in the FIN_WAIT_2 state, the TCP module can still receive messages from its peer... Closing a "half open" TCP connection At a later time, the other TCP module will also invoke a close operation The TCP module will also send a FINISH request to its peer. There is a small difference in this close procedure... Messages exchanged in closing the half open TCP connection (on behalf of the server): Server sends FIN (disconnect) request: The client acknowledges the FINISH request: NOTE: The client sends an ACK for the FIN request Then the client invalidates the ACK number Now the client's TCP state is completely empty !!! Now, you may be thinking that the TCP close operation at the client is completed NO !!!, not yet... Reason: The ACK message (for the FIN request can be lost: The server would then time out and retransmit the FIN request: This would lead to an abnormal termination of the TCP connection: To minimize the likelihood of abnormal termination of half open TCP connection, the client will: wait 2 x MSL (Maximum Segment Livetime) before removing the TCP state record MSL is the maximum amount time that a packet can "live" in the Internet (due to routing errors, packets can be routing to very strange places in the Internet, but through the TTL field, the lifetime of packets is limited.) We can't never be sure what MSL really is (depends on how congested different routers are... MSL is set conservatively to 120 sec (2 min). So the client will wait 4 min (2 × MSL) before removing the TCP state record Example: ACK is lost Server retransmits the FIN request The client retransmits the ACK... Finally, when the server receives the ACK, it deletes the TCP state record: Now the server does not have any record of this TCP connection After 2 × MSL delay, the client will also delete the TCP state record: Note: There is still a slight chance that after 240 sec (2 x MSL) of waiting, a retransmitted FIN request arrive. But such an event is rare Simultaneous closing Because each termination is indepedent of each other, it is possible that both TCP modules initiate the close operation simultaneously. The messages exchanged in such case are as follows: Notes: Both TCP modules send a FIN request Both TCP modules reply with an ACK After sending the ACK, each TCP protocol module must wait 2 x MSL (240 sec) before removing the TCP state record
