Home > Experiential Learning > Experiential Learning of Networking Technologies: Understanding TCP States – Part 2

Experiential Learning of Networking Technologies: Understanding TCP States – Part 2

5 TCP Connection Closure: FIN_WAIT2 state

A TCP connection will reach the FIN_WAIT2 state only when it receives the ACK (2) message from the other side for the FIN (1) message it has sent. This also implies that other side has received the FIN (1) message and moved to the CLOSE_WAIT state. This is a normal communication process where both the network and the applications are behaving as expected. If the application for which the TCP connection is in CLOSE_WAIT state has no more data to transmit, the application invokes the close() call and TCP will send the FIN (3) message and move to the LAST_ACK state. The originating application that initiated connection close will remain in the FIN_WAIT2 if the second FIN (3) message is lost, implying network disturbance. Below we describe the experimental exercises to define network conditions depicting the TCP connection states of two communicating applications.

Experiment 5:
TCP State FIN_WAIT2 ($H_{2}$) and CLOSE_WAIT ($H_{1}$)

We start a netcat server on $H_{2}$. As before, it is necessary to have a client program that continues to send data even after the other side has initiated connection close. Hence, we use the previously described Python client program on $H_{1}$ to establish communication and exchange some data, as shown in the upper panels of Figure 11 and Figure 12. At this point, the TCP connection is in the ESTABLISHED state as shown by the output of the first command in the lower panel of Figure 12. The client program tcp_client.py is invoked to send 20 iterations of data transmission (option -c) at an interval of 20 seconds (option -d), and the data transmitted is the current date and time as can been seen in the upper panels of these two figures.

PIC
Figure 11: FIN_WAIT2 state while receiving data
PIC
Figure 12: CLOSE_WAIT state while other side initiated close

When the netcat application is closed on $H_{2}$ at time 11:19:22, it sends a FIN (1) message to $H_{1}$ and moves to the FIN_WAIT1 state. The application on $H_{1}$ receives this FIN (1) message, responds with ACK (2) and moves to the CLOSE_WAIT state. Since it has more data to send, it does not send the FIN (3) message and continues to remain in the CLOSE_WAIT state (as shown by the output of the last command in the lower panel of Figure 12). However, when $H_{2}$ receives the ACK (2) message, it moves to the FIN_WAIT2 state as shown in the lower panel of Figure 11 at time 11:19:25.

Experiment 6:
TCP State FIN_WAIT2 ($H_{2}$) and LAST_ACK ($H_{1}$)

In the above experiment, when the FIN (3) message sent by the application on $H_{1}$ does not reach $H_{2}$, then although $H_{1}$ will move the TCP connection state to LAST_ACK, the state on $H_{2}$ will continue to be FIN_WAIT2. To realize this situation, one must carefully understand the transitions. When the FIN (1) message sent by $H_{2}$ is received, $H_{1}$ will send the ACK (2) message and move to the CLOSE_WAIT state. When $H_{2}$ receives this ACK (2) message it will move to the FIN_WAIT2 state. When $H_{2}$ has finished sending its data, it will send the FIN (3) message that should be lost for the purposes of this experiment. Thus, one must carefully manage the timing of these events as shown in Figure 13 and Figure 14.

PIC
Figure 13: FIN_WAIT2 awaiting FIN from other side
PIC
Figure 14: Transition from CLOSE_WAIT to LAST_ACK

The TCP application on $H_{1}$ is invoked, which sends 3 data packets starting at time 15:33:35, at an interval of 10 seconds (option -d 10) as shown in the upper panel of Figure 14. At 15:33:55, the application is aborted on $H_{2}$ (upper panel of Figure 13), hence the FIN (1) message is sent. Once the ACK (2) message is received, the TCP connection state on $H_{1}$ moves to FIN_WAIT2, as shown in the lower panel of Figure 13. The application on $H_{1}$ will wait for 10 more seconds before invoking close() at 15:34:05. At time 15:34:01, a firewall rule is invoked on $H_{1}$ to drop the FIN packet, as in the lower panel of Figure 14. Note that $H_{1}$ has not yet sent the FIN packet – it is still in the CLOSE_WAIT state as shown by the output of the fourth command in the lower panel. At time 15:34:05, when the application on $H_{1}$ invokes close(), it sends the FIN (3) packet and moves to the LAST_ACK state as shown by the output of the last line in the lower panel of Figure 14. However, this FIN (3) packet is dropped by the firewall rule, hence it does not reach $H_{2}$. Thus, the state of the TCP connection on $H_{2}$ remains FIN_WAIT2.

6 TCP Communication state CLOSING

You will notice that we have not discussed the CLOSING state. This state is experimentally difficult to observe, because it requires a very high-precision timing of events and is therefore infeasible to create in typical lab scenarios. Thus, we will not define an experimental exercise for this state, but we will describe the general communication scenario that may lead to this state. This state can only be reached when both applications connected by a TCP connection decides to close the connection almost at the same time. Thus, both the applications send the FIN (1) message and move to the FIN_WAIT1 state awaiting the ACK of its FIN. When in this state, when the first application receives FIN (1) from the second application, it sends the ACK (7) message and moves to the CLOSING state. Similarly, when the second application receives FIN (1) from the first application, it sends the ACK (7) message and moves to the CLOSING state as well. Both applications will receive ACK (7) messages, and they will then move to TIME_WAIT state.


Pages ( 4 of 5 ): « Previous123 4 5Next »

Leave a Comment:

Your email address will not be published. Required fields are marked *