[sydney]

I have an LV2009 application that uses TCPIP to talk to embedded code that we wrote and installed on a mvme5600 board to do some custom data acquistion and processing and have found that when my TCPIP client does an 'active close', I have to wait about 4 minutes before I can reestablish the socket once again with the same IP and port number. When the server does the 'active close' we can set the SO_LINGER' option to reduce the TIME_WAIT to something that we need as this connection is only used on a dedicated network so I am not worried about creating 'incarnations' receiving old data. Is there any way that I can change the TIME_WAIT in my LabVIEW VIs?

I have thought about changing port numbers for new connections, but we really need to use the same IP and port number.

This post has been edited by sydney: 08 January 2010 - 01:05 PM

[Mark Yedinak]

sydney, on 08 January 2010 - 01:01 PM, said:

I have an LV2009 application that uses TCPIP to talk to embedded code that we wrote and installed on a mvme5600 board to do some custom data acquistion and processing and have found that when my TCPIP client does an 'active close', I have to wait about 4 minutes before I can reestablish the socket once again with the same IP and port number. When the server does the 'active close' we can set the SO_LINGER' option to reduce the TIME_WAIT to something that we need as this connection is only used on a dedicated network so I am not worried about creating 'incarnations' receiving old data. Is there any way that I can change the TIME_WAIT in my LabVIEW VIs?

I have thought about changing port numbers for new connections, but we really need to use the same IP and port number.

The length of the TCP TIME-WAIT is dependent on the maximum segment lifetime. The TIME-WAIT is defined as twice the maximum segment lifetime. I have been using the TCP VIs of LabvIEW for years and have not encountered the extreme delay taht you are seeing. This leads me to believe that the issue is with the network settings on your machine, not with the LabVIEW code. I would look to see where your maximum segment lifetime is getting set and change that. This would have to be done outside of LabVIEW or NI stuff.

[mesmith]

In vi.lib\Utility\tcp.llb there's a VI called TCP Get Raw Net Object that will return the current socket handle. You could then use the socket handle as an argument into a CLN call into a DLL that could then call the Winsock DLL (assuming you're on Windows) and set the TIME_WAIT value... I think... I haven't done it. Or you could just ask yourself if you really need to reuse the same client side port or just let the client grab the next available one to reconnect to the server. This would be a lot easier.

Also, are you sure the handshaking with the server is happening exactly the way you think it is? Have you looked at the transaction with a port sniffer like Wireshark?

Mark

[sydney]

According to the R. Stevens book on Network Programming the TIME_WAIT state is 2 MSL and every implementation of TCP must choose a value for MSL where the recommended value for MSL is 30 secs to 2 minutes which means TIME_WAIT is between 1 and 4 minutes. I don't know what NI is setting this to, but on our server side there is a standard socket option called SO_LINGER that allows us to set what we want which, for our application is very short (1 minute). I would like to do likewise at the server end since the 'active close' will be initiated from LabVIEW if the client has to be shut down and then restarted a short time later. This scenario would occur if a user accidentally closed the NI program and we needed to immediately reconnect to the server.

This is good info that I will look into. And yes, we are using Wireshark to monitor the messages, so I am pretty sure I have to adjust the socket options and will definately look at the raw socket stuff. As for changing ports, the server code is hard coded into a custom kernel using WindRiver and the appropriate BSP for the MVME5600 board, so we really have to keep the code small and fixed on the embedded side.

[Phillip Brooks]

I've successfully tinkered with this socket setting to deal with port exhaustion.

You can use the get raw object vi Mark mentioned to modify the LabVIEW TCP ref and set the socket variable 'TcpTimedWaitDelay'. There are conflicting entries on MSDN as to the minimum value; some state zero and others 30. We used 30 for our port exhaustion problem with success but I never tried a lower value.

The concern would be DoS attacks on a given port, but your connection seems to be isolated so it shouldn't hurt to try. I would refrain from placing this in the registry though; I believe it would apply to all sockets and might make your computer vulnerable on any other network interfaces...

[mesmith]

sydney, on 11 January 2010 - 04:00 PM, said:

According to the R. Stevens book on Network Programming the TIME_WAIT state is 2 MSL and every implementation of TCP must choose a value for MSL where the recommended value for MSL is 30 secs to 2 minutes which means TIME_WAIT is between 1 and 4 minutes. I don't know what NI is setting this to, but on our server side there is a standard socket option called SO_LINGER that allows us to set what we want which, for our application is very short (1 minute). I would like to do likewise at the server end since the 'active close' will be initiated from LabVIEW if the client has to be shut down and then restarted a short time later. This scenario would occur if a user accidentally closed the NI program and we needed to immediately reconnect to the server.

This is good info that I will look into. And yes, we are using Wireshark to monitor the messages, so I am pretty sure I have to adjust the socket options and will definately look at the raw socket stuff. As for changing ports, the server code is hard coded into a custom kernel using WindRiver and the appropriate BSP for the MVME5600 board, so we really have to keep the code small and fixed on the embedded side.

OK, so maybe I'm getting confused here - the IP address/port that defines your server address is fixed - correct? This would be common practice. When your client disconnects from the server, it sends a close message to the server and the server closes the connection and sends the close handshake and the client goes into the TIME_WAIT state. The protocol says that only one end of the connection is required to go to TIME_WAIT (which is a default 4 minutes on Windows) and common socket implementation lets the server side (the accept socket) release the socket immediately and makes the initiate socket (the client side) go to TIME_WAIT (edit) - this probably should say the endpoint that initiates closing the connection is required to go to TIME_WAIT which in this case is the client - (end edit). So, the server can now immediately accept a new connection on the same port. The client cannot initiate a new connection on the same port until the TIME_WAIT completes. Here, most clients (like LabVIEW's default behavior) just use the socket library's ability to auto-select the client side port to allow immediately reconnecting to the server by just grabbing the next available port. Since the client initiates the connection, it knows 1) the socket handle and 2) the server/port it's connected to so it has full control and access to the stream. There's seldom any need to worry about which client side port to use or even which is in use. Of course, your situation may be different and you may really need to re-use the same port. Then, you're right - you need to force the TIME_WAIT to something other than 4 minutes.

Mark

[rolfk]

sydney, on 11 January 2010 - 04:00 PM, said:

I don't know what NI is setting this to, but on our server side there is a standard socket option called SO_LINGER that allows us to set what we want which, for our application is very short (1 minute).

LabVIEW doesn't tinker with TCP/IP options a lot. It sets everything that is needed to make asynchronous sockets work reliable and leaves the rest at whatever the OS chooses to create a socket with.