- 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
- It is possible for
one side
to close its TCP connection
without
having
the other end
of the connection
to be closed...
- 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)
- The TCP module
that closes its TCP connection
will no longer be able to
transmit
- 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.
- The
socket application
programming interface (API)
do not support
a one-sided close operation....
- 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
- Send an ACK reply to
the sender
- 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...
- Client sends a FIN request:
- 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:
- The ACK message (for the
FIN request
can be lost:
- The client sends an
ACK for the
FIN request
- 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
- MSL is
set conservatively
to
120 sec (2 min).
Example:
- ACK is
lost
- Server retransmits
the FIN request
The client retransmits the ACK...
- wait
2 x MSL
(Maximum Segment Livetime)
before
removing the
TCP state record
- 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:
- Server sends
FIN (disconnect) request:
- 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
- There is still a slight chance
that after 240 sec (2 x MSL)
of waiting, a
retransmitted FIN request
arrive.
- 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
- Both TCP modules
send a FIN request