TCP Connection Management (3)

When initialized, TCP starts in the CLOSED state.

Usually an imme-diate transition takes it-either the syn_sent or LISTEN state, depending on whether the TCP I S asked to perform an active or passive open, respectively.

The established state is where data transfer can occur between the same ends in both directions.

Simultaneous close, which is a form of double active close, uses the CLOSING state.

The transition from SYN_RCVD back to LISTEN are valid only if the SYN_RCVD state were entered from the LISTEN state (The normal scenario),

not from the Syn_sent state (a simultaneous open).

This means so if we perform a passive open (enter LISTEN), receive a SYN, send a SYN with an ACK (enter SYN_RCVD), and T Hen receive a reset instead of an ACK, the endpoint returns to the LISTEN state and waits for another connection request T O arrive.

Time_wait (2MSL WAIT) state

The TIME_WAIT state is also called, the 2MSL WAIT state. It is a state in which TCP waits for a time equal to twice the Maximum Segment Lifetime (MSL),

Sometimes called timed wait.

It is the maximum amount of time any segment can exist in the network before being discarded.

We know that this time limit was bounded, because TCP segments is transmitted as IP datagrams,

And the IP datagram has the TTL field or Hop Limit field limits it effective lifetime

On Linux, the value net.ipv4.tcp_fin_timeout holds the 2MSL wait timeout value (in seconds).

...

This lets TCP resend the final ACK in case it is lost.

The final ACK is resent not because the TCP retransmits ACKs (They does not con-sume sequence numbers and was not retransmitted by TCP),

But because the other side would retransmit its FIN (which does consume a sequence number).

Indeed, TCP would always retransmit FINs until it receives a final ACK.

Another effect of this 2MSL wait for state is and the TCP implementation waits, the endpoints defining that connection

(Client IP address, client port num-ber, server IP address, and server port number) cannot be reused.

That's connection can reused only if the 2MSL wait is over, or if a new connection uses an ISN ' that exce EDS the highest sequence number used on the previous instantia-tion of the connection [RFC1122],

Or if the use of the Timestamps option allows the disambiguation of segments from a previous connection Instantia tion to isn't otherwise be confused [RFC6191].

Unfortunately, some implementations impose a more stringent constraint. In these systems, a local port number cannot being reused while this port number is the local port number of any end Point, is in the 2MSL wait for the system.

With the Berkeley sockets API, the so_reuseaddr socket option enables the bypass operation.

It lets the caller assign itself a local port number even if that port Num-ber are part of some connection in the 2MSL wait state.

We'll see, however, which even with this bypass mechanism for one socket (address, port number pair),

The rules of TCP still (should) prevent this port number from being reused by another instantiation of the same Connec TioN is in the 2MSL wait state.

Any delayed segments, arrive for a connection while it's in the 2MSL wait state is dis-carded.

Because the connection defined by the Address/port 4-tuple in the 2MSL wait state cannot is reused during this ti Me period,

When a valid connection was finally established, we know that delayed segments from the earlier instantiation of this Connec tion cannot is misinterpreted as being part of the new connection.

The implication (meaning, impact) is so if we terminate a client, and restart the same client immediately, that new client Cann OT reuse the same local port number.

This isn't ordinarily a problem, because clients normally use ephemeral ports assigned by the operating system a nd don't care about the assigned port number is.

This was important to know because a client that makes a large number of connections quickly (especially to th E same server) could conceivably has to delay while other connections termi-nate if ephemeral ports is in Shor T supply.

With servers, however, the situation is different.

They almost always use well-known ports. If we terminate a server process that have a connection established and immediately try to restart it, the server Canno T assign its assigned port Num-ber to its endpoint

(It gets an 'Address already in USe ' binding error), because that port number was part of a connection that's in A 2MSL wait state.

Client

...

As we expect, the client cannot do this, because Port 2091 are part of a connection, which is in a 2MSL wait state.

Once the Wait is over (1 minute in this Linux machine), the client attempts to connect again, but the server exited when the connection is interrupted the first time,

So it is refused. We shall see how TCP Reset segments is used to signal this connection refused condition in section 13.6 .

Here we see that even though the same connection (4-tuple) are being used again before the 2MSL wait state expires ,

The use of THE-A option have forced the connection to be allowed.

Of course, this is all taking place on the same computer.

What if we try the same thing again and establish the connection from another host?

We observe that irrespective of the-a flags on the client, and the 2MSL wait time is induced.

After this, the client attempts to contact the server, which have already exited.

One interesting thing happens if we switch the client and server machines.

We'll now use Windows as the server and Linux as the client and repeat the experiment.

Connect () Error:connection refused-means client do not work

Bind () Error:connection refused-means client works, but server does work

At this point we would expect local port 32843 to is unavailable, but because of the way-a works on Linux, we AR E allowed to make use of it.

This was a violation of the original TCP specification, but it was allowed by [RFC1122] and [RFC6191], as mentioned Before (those convincing facts).

These specifications allow a new connection request to arrive and being accepted for a connection that's in the Time_wait St Ate

If there is a strong reason to believe this segments on the new connection would not being confused with SEG ments on the previous InstantiatioN of the connection

Based on a combi-nation of the sequence numbers and timestamps.

Quiet Time Concept

But this (2MSL protection mechimism) works only if a host with connections in the 2MSL wait does not crash.

What if a host with connections in the TIME_WAIT state crashes, reboots within the MSL, and Immediat Ely establishes new connections using the same local and foreign IP addresses and port numbers corresponding to the L Ocal con-nections

That were in the TIME_WAIT state before the crash?

In this scenario, delayed segments from the connections then existed before the crash can be mis-interpreted as Belonging to the new connections created after the reboot.

This can happen regardless of the initial sequence NumbeR are chosen after the reboot.

To protect against this scenario, [RFC0793] states that TCP should wait a amount of time equal to the msl before creating any new connections after a reboot or crash.

This is called the quiet TimE.

Few implementations abide by this because most hosts take longer than the MSL-reboot after a crash.

Also, if appli-cations use their own checksums or encryption, errors such as these is easilydetected.

Fin_wait_2 State

In the fin_wait_2 state, TCP have sent a FIN and the other end have acknowledged it.

Only if the application (the passive open end) performs this close (and it FIN is received) does the active closing TCP Move from the fin_wait_2 to the TIME_WAIT state.

This means, that one end of the connection can remain in this state forever.

The other end was still in the close_wait state and can remain there forever, until the application decides to ISS UE its close.

Many implementations prevent This infinite wait on the fin_wait_2 state as follows:

If the application that does the active close does a complete close and not a half-close indicating that it expects To receive data, a timer is set.

If The connection is idle when the timer expires, TCP moves the connection to the CLOSED state.

In Linux, the variable net.ipv4.tcp_fin_timeout can is adjusted to control the number of seconds to which the Tim ER is set. Its default value is 60s.

Simultaneous Open and Close transitions

Todo

TCP Connection Management (3)