TCP Error 60 on a cRIO 9014

[TLE]

Open the Simple Data Server.vi and the Simple Data Client.vi from the LabVIEW examples and add them to a project with a cRIO 9014.

Run the Simple Data Server.vi on the cRIO 9014.

Set the IP address to that of the cRIO 9014 and run the Simple Data Client.vi on a Windows XP machine that is on the same LAN as the cRIO 9014.

Stop the Simple Data Server.vi.  This will also stop the Simple Data Client.vi.  This is expected behavior.

Now run the Simple Data Server.vi.  I get Error 60.  The only was to get rid of this error seems to be either changing the port number on both VI's or to restart LabVIEW.

Can anyone see if they can repeat this problem?  Is this expected behavior?

[TLE]

One more piece of information.

If I wait about 1 minute and try to restart the Simple Data Server.vi, no Error 60 is encountered.

I already saw the existing topics on the forum regarding Error 60 and tried closing the Listener ID AND Connection ID both.  This made no difference.

[TLE]

Also,

The problem is unqiue to the cRIO 9014.  I can run both VI's on the same Windows XP machine or each on a different Windows XP machine and no Error 60 occurs.

[CharlieM]

This was reported to R&D (# 4h3G3QB7), but was determined to be expected behavior for VxWorks Controllers (the 9012 and 9014). The TCP stack will hold on to the connection for a minute or so before officially closing.

[TLE]

It may be expected behavior but it is not desirable. 

[Bassett_Hound]

Hi TLE,

I wanted to probe a little further and ask what is the desirable behavior your looking for and why?

The reason this is expected behavior is the TCP stack for VxWorks like many TCP implementations will hold on to a port for about a minute following a connection close.  This is often referred to as the Timed Wait state.  The reason for the Time Wait state is that if you close and re-open a TCP port quicly, stale data from the old connection may arrive and be mistaken for data on the new connection. 

Hope that explains the behavior a little better.

Bassett

[TLE]

I would expect that when a connection is closed, all data associated with that connection is destroyed and that a new connection can be opened immediately with the assurance that new data will be for that new connection only.

Most likely this issue will not be a problem for me other than during testing.  My test plan calls for me to stop and restart the application on the cRIO.  When I do, I have to wait a full minute before my HMI reestablishes communications.  Although annoying, this is not a show stopper.

The end application will be an executable program running on the cRIO.  The only time it should ever stop is upon a power failure or hardware fault.  When the cRIO comes back up, the HMI should be able to restablish communications immediately.  However, this remains to be tested.

[InfiniteNothing]

What is the best way to avoid the 1 minute delay. I'm encountering it too and it's terribly frustrating because I'm debugging and I need to run "Create Listener" often. 

Two solutions I'm considering: A) Saving the listener ID in a file so I can reacquire it and re use it when the program restarts within a minute. B)Is there a way to override that behavior? C) Just reboot the CRIO every time I need to restart the program. 

[gsussman]

The issue you are seeing with the TCP connection is due to the socket connections being opened on the RT platforms without the (SO_REUSEADDR) option set. Without the reuse address option set, if the server closes the connection, per RFC793, the connection goes into a TIME_WAIT state and is unable to connect for 2X the segment lifetime(~1 min). If the client closes the connection first, the port is returned to an available state.

Essentially what this means is that if you create a listener on port 2700 of the RT system, and the RT system then initiates a TCP Close function before the computer on the other end closes the socket, you loose access to that port for 2X the segment lifetime (~1min)

The most reliable way to handle this situation is to implement dynamic port assignments on the RT system. You create a listener on the RT system on an "initial connect port". This port number is known by all systems that connect to the RT system (for purposes of this discussion I will use port 2700).

When a system wishes to connect to the RT system, it initiates a connection to port 2700 on the RT system.

The RT system, upon seeing that there is a listener, will create a new listener with no port number specified (dynamically assigned). It will then transmit a single U16 back across the connection on port 2700 to tell the connecting system what port to connect to next.

The RT system will then wait for 5 seconds before closing the connection on port 2700 (this allows time for the client to close it's connection first)

Having this new port information, the connecting system will close it's TCP connection to the RT system on port 2700, thereby allowing port 2700 to be closed on the RT system without going into the "timed wait" state.

The connecting system then opens a connection to the new dynamically assigned port that it received via the single U16 value from the RT system.

Using this method, port 2700 always remains open and available to connect to. If something happens to your dynamically assigned port and the socket goes into "Timed-Wait" then the next connection attempt will roll over to the next available port.

This problem shoes up as a "gotcha" because Windows uses SO_REUSEADDRESS for opening up socket connections. In this instance if a port goes into a "Timed-Wait" state AND you try to create a new listener on that port, the port becomes available. If you develop your code on a Windows to Windows platform then transfer to an RT platform, you will see this problem.

BTW: This dynamic port assignment is the same way that LabVIEW connects to the RT systems to ensure that they don't loose the ability to connect if something happens.