TI-RTOS-MCU: Issue with TCP Client reconnect using TM4C129E Launchpad and TI RTOS NDK

Hi AJ,

What you've encountered is a well known issue and is part of the TCP protocol itself. The behavior of close() varies depending on which side of the connection calls close first(), and this also dictates who must enter the TIME_WAIT state.

There are 2 types of close() calls - "active" and "passive":

1. Active Close:
   1. the side which calls close() on a connected socket first performs an active close
   2. this socket will enter the TCP TIME_WAIT state. This is part of the TCP protocol.
2. Passive Close:
   
   1. This is when close is called on a socket, due to the other side of the connection calling close
   2. For example, the other side (active closer) called close, which results in this side's sockets APIs failing due to that (e.g. recv() returns a failure) and then since the socket API failed, the close is called in result (this is the passive close)
   3. this socket will get clean up relatively fast, as it *does not* need to wait in TIME_WAIT

The general consensus is that applications should be designed so that the client calls close first (active closer) therefore allowing the server to close quickly (passive closer). This is to prevent a build up in the server of sockets stuck in TIME_WAIT.

Note that it is possible to force a socket to exit time wait by configuring it to be a linger socket and setting its linger time to zero. However, this is seen as a hack and not recommended.

Please refer to the following thread for further details:

https://stackoverflow.com/questions/3757289/when-is-tcp-option-so-linger-0-required

and especially the answer here.

Steve

(edit: fixed broken link)

AJ,

My bad, I accidentally copied the wrong link in my other post. I fixed it there but here it is also: https://stackoverflow.com/a/13088864

This too: http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html

AJ_ee said:

And the only thing I could do to reduce that delay is select a small value for SO_LINGER? Did I get that right?

Yes, your options are to either wait (recommended) or configure the socket to be a linger socket with a timeout of zero (not recommended, do at your own risk).

Like I mentioned before, the linger + zero timeout isn't recommended. The reason is that it's a bit of a hack; when you do this, your TCP connection will not close normally. Hopefully the shared links will help explain that better.

AJ_ee said:

Also, just curious, what is the default value for this delay? Is this value standard or just here in TI NDK?

There is no default setting - sockets are not linger sockets by default. You would need to configure your socket to be a linger socket by calling setsockopt() with the SO_LINGER option.

In that call, you must provide a struct linger in which you specify the linger time.

So, you might say the answer is whatever you initialize it to be :)

AJ_ee said:

Whenever I reconnect, it fails for some period of time and then eventually I am able to reconnect again. But I have to wait for sometime. During the time that reconnection fails, I noticed an error in bind. and using fdError, I get error 48 which I think is EADDRINUSE. So what I did was call setsockopt and enable SO_REUSEPORT. This eliminated the error in bind. However, now I get an error when calling connect().

Just wanted to clarify/confirm one detail in the above (from your original post) - that you are trying to re-use the same socket (that you closed previously) to re-connect again to the server app?

Steve

Hi AJ,

AJ_ee said:

Just to clarify,when you say linger socket, SO_LINGER is set to 0 right? Or does it mean that as long I call setsockopt with SO_LINGER, even if it is set to a non-zero value, that's also a linger socket?

No, and yes. Let me define it like this:

• A Lingering Socket is a socket that is currently blocked, awaiting the Linger Time to expire, before proceeding on to actually closing and having its resources freed.
• A Linger Socket is a socket that will linger for the Linger Time once that socket is closed

So, the time value has nothing to do with being a linger socket. When you set the Linger Time to 0, it is still a linger socket, but it will just linger for a time of 0 (i.e. it will try to linger but immediately timeout so doesn't really linger at all).

AJ_ee said:

If I configure socket with an SO_LINGER that's non-zero, that's still okay right

Yes this is OK. You're "supposed to" configure a non-zero time.

The Linger Time of 0 is the one that's questionable and being debated in those linked threads.

AJ_ee said:

how long is TIME_WAIT? Is this value standard for any TCP stack?

The standard is "2 x MSL (max segment lifetime)"

But, it seems that MSL varies depending on the implementation.

In NDK, it's set as follows:

// in tcp.h
/* Timer Constants (in 1/10 second ticks) */
#define TCPTV_MSL               300     /* max seg lifetime (30 sec) */

...

static void TcpEnterTimeWait( TCPPROT *pt )
{
 ...
    pt->TicksWait2   = 2 * TCPTV_MSL;

So should be 1 minute.

Steve