How to force Windows to relinquish discarded TCP/IP port.

[VIagra]

Our test-environment incorporates a TCP/IP device that requires two TCP/IP connections from the LabVIEW application - one created with "TCP Open Connection.vi", and one created with "TCP Listen.vi". When the LabVIEW application quits, it closes both connections using "TCP Close Connection.vi". However, it looks like LabVIEW and/or the OS (WinXP) continues to reserve resources even though we've explicitly closed the connection _and_ power-cycled the device! "Ill-formed address" errors are often returned by TCP Listen when subsequent executions of the application attempt to Listen for a connection (at the same port#). Repeatedly re-running the application and/or re-launching LabVIEW are our best cures for this
problem.
How might LabVIEW coerce the OS to let go of the port faster? (Like with a CIN/API call to the OS, maybe?)

Cheers, Bill C

[altenbach]

I don't have a direct solution, but it would be very useful to find out exactly what the problem is here.

Let's assume that your "device" is not running LabVIEW (e.g. RT), just the PC side. Is this correct?

It is not entirely clear what's going on, so I have some troubleshooting tips. I suspect that the "device" is not closing the connection properly, leaving the PC e.g. in one of the FIN-WAIT or CLOSE-WAIT states. (Of course power cycling one side will definitely not close the connection properly, leaving the connection hanging. The FIN-WAIT-2 timeout is about 5 minutes, I think). For more information on the terminology, see section 3.2 of RFC793.

What is the device? Maybe it's quite primitiv
e and has a faulty/incomplete TCP/IP implementation, e.g. a "lite" version with some details missing or buggy.

(1) Once the problem occurs, go to a command prompt and type "netstat -an" and search for the connection involving the ports of your LabVIEW application. What is the connection state?

(2) Hook up a packet sniffer and record the packet exchange during connection closing. (e.g. Ethereal)

(3) How reliable is the connection? Do you have a lot of packet loss and retransmissions?

(4) Do you run any kind of personal firewall software on the PC?

Interestingly, the "close connection.vi" has an "abort" terminal that, according to the online help, is "reserved for future use". Maybe this will allow to RST the connection immediately in future versions?

Most likely, you don't need to wire a local port for the "tcp open connection.vi". In this case the OS will choose a random ephemeral port and you won't have any conflicts. (Do
you know if the device insists on a certain source port for incoming connections?) You still need to troubleshoot the issues for the server port used in TCP-listen.

[VIagra]

The info about states is a perfect place to start and the netstat suggestion offers a great diagnostic tool.

For the record, the device is not running LabVIEW.
On pwr-up, it waits for our LV-app. to connect to it - at a specific port. then, immediately, trys to connect to us. Besides power-cycling it, we have no control over it's maintenance of TCP connections. Connection - no firewall, dedicated NIC & subnet, 5feet Cat.5 - should be very reliable, though I have little clue. The little LEDs aren't going crazy!(?)
Yes! The intended function of that "Abort" boolean is intruiging.

Many THANKS "altenbach" !