LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Changing TCP/IP timeout conditions?

I am running LV8.5 across several different platforms (Mac, Linux, Windows).  I am using the standard LV TCP/IP listen/connect vi's within a larger custom network communication vi, and I am trying to make my application both platform-independent and robust against various types of network and/or LabVIEW failure.  I am encountering a problem after I either stop the vi which controls the network connection or kill LV to simulate an overall "crash" of the application.  After the stop/crash, I want to restart the network connection vi immediately; however, I am running up against the OS's built-in "Timed Wait", in which the stale socket connection is not immediately killed.  If I restart the vi too soon, the TCP/IP Listen vi returns "Error 60", since, obviously, the port I have chosen is still reserved by the system for the previous socket connection.  The idea behind the "Timed Wait" is to avoid killing active sockets that just don't happen to be passing any messages within a (presumably short) period of time, but the forced wait I am experiencing prior to reconnection is not optimal for my application.  Furthermore, the amount I have to wait is platform-dependent--there is a noticeable difference between Unix-based systems and Windows, for example.  Among other requirements, I would like uniform reconnection behavior regardless of platform, so what I am trying to do is find a way to set the timeout condition just for this socket, while leaving the overall "Timed Wait" for the system at the default value.  If the "socket timeout" value is in fact user-definable within LV, then I can determine by trial and error the optimal value that allows me to reconnect in a timely fashion while still avoiding timeouts on an active connection.  But at this point I don't see how to set this value at all, since the relevant TCP/IP vi's do not have the appropriate input wires.  They do have inputs that determine their own timeout conditions, but this is only for determining after what amount of time, for example, the Connect vi returns a failure to connect, not the timeout value that determines when to kill a stale socket after a previously-successful connection has been terminated.

A solution that was offered to a previous discussion board request based on the same Timed Wait/Error 60 problem was to change/increment the port for the new connection so that it is not attempting to use exactly the same resources as the old connection.  I do not want to do this, since other aspects of my program currently require the port to be set to a specific value (in addition to the lesser concerns I have about using up the available port resourcess if the vi experiences multiple failures in rapid succession).  So again, what I am hoping to find is a way to change socket-specific timeout conditions within LV.  If the answer is, in fact, "LabVIEW does not support this feature", that is OK--as long as I know that for sure, then I can implement other work-arounds.  For example, I've already build a "While Error...wait N seconds" into the reconnect step of my network communication vi; however, having the ability to define for myself the interval after which I can reconnect would still be preferable.

Thank you,
Kyler
0 Kudos
Message 1 of 3
(4,050 Views)
Hi kkuehn,
 
From what I understand, if you are able to change that option yourself in the operating system environment (the TCP port-release time, for instance), you are able to change that option with LabVIEW.  The trick would be in finding out where that option is in each operating system.  I don't immediately know, myself.  However, I will investigate this further and see if there is more information that I can pass along to you.
 
Regards,
Kevin S.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 3
(4,020 Views)

Hi kkuehn,

I've talked to a few more application engineers here, and this issue sounds like it's an operating system setting.  Could you change this setting?  ...potentially, yes.  The hard part would be in finding out where to change it for each operating system.  I don't really have any paths to point you down though in your search.

There's one option you could investigate.  Before trying to reopen the "stale" port, you could try closing that port at the beginning of the program.

Perhaps someone from the community, who has more operating system knowledge as to this option, could respond to this post as well.

I hope this helps,
Kevin S.
Applications Engineer
National Instruments

0 Kudos
Message 3 of 3
(3,996 Views)