Using LabVIEW 6i w Win NT or 95/98 et al: how do you keep a TCP/IP open connection 'open'. The application closes the connection even though the refnum is still active (valid.)

Question

Actually, I open the TCP/IP connection and pass the connection ID through. Each command to/from (cycle) the UUT successfully executes. The refnum for the connection ID is then passed via a shift register in the while loop. i am using the type cast (4X) function to determine the validity of the connection and case statements. If the refnum is non-zero it assumes the connection is still open; if the result is zero, then the connection is closed and a new session opened in that case. What is happening is that the connection has closed and the refnum is still nonzero after the type cast function; su
bsequent commands to the UUT then produce Error 1 for the TCP/IP function (there was no open connection, so there could be no write occurrence.) Obviously, this probably shouldn't be happening. If someone can give me some idea of what I am not doing, or am doing wrong, I sure would appreciate it. In the event that I open and close a connection for each command to(from)(cycle) the UUT everything works. It is extremely slow. The connection should remain open according to all the pointers in the Help and TCP/IP function descriptions. Some of this application is proprietary, so not sure how much of an example I could use to illustrate from a VI, but if this doesn't get any where, I will see what i can do to better illustrate the problem...Thanks. T.Raper

Answer 1

I believe this is a related question. I am developing a LV application the uses TCP/IP to control up to 8 devices-under-test (DUT) at one time. They start and finish testing at arbitrary times relative to each other, and the IP addresses are not known until the DUT arrives. I have some question on what is the best way to manage the TCP/IP handles.
Presently, I have 8 Global IP addresses (one per testing site) that are updated as DUTs arrive and depart, and then whenever I need to communicate with a DUT I use TCP-Open, Write/Read, and TCP-Close. I do this Open/Write/Close each time there is a message to be sent to a DUT. This is basically working, but I notice that the OS (Windows XP or 2000) is running through local TCP/IP ports at a ferocious rate due to the TIME_WAIT behavior of Closed TCP/IP ports (It takes many minutes for a local port to become available again after being closed). If I am not careful, I can quickly exhaust the pool of OS ports by using tight polling loops or other very quick DUT accesses. I have tried not to do that in order to avoid running out of handles, but it is still very wasteful of ports.
While it is working, I feel so dirty burning through these handles like this since they appear to be a precious resource. I really cannot easily merge multiple Read/Writes into a single Open/Close since there are dozens of otherwise unrelated tests that communicate with the DUT as a part of their functionality. The tests are even in different subVI's that are accessed via a vi-server, and only one is loaded at a time.  
I thought that a cute idea would be to cache the handles in Globals, and wrap the Open to use the cache if valid, but reading this thread is making me think it is a lot of effort -- I believe I would need to keep a VI running as a "IP Connection Server" at all times and use some form of messaging to get it to Open/Close TCP connections as needed. Since the DUTs arrive at aribitrary times, and with random IP addresses, I cannot establish all the TCP handles ahead of time -- they would need to be created dynamically. It is much more difficult than simply keeping the Connection IDs in global variables -- the VI that Opened them must not be allowed to terminate.
So... I am curious...... is it really that bad to Open/Close as frequently as I am doing it? Does it make me a bad person? I understand it is inefficient use of time, but the simplicity it brings to the structure seems huge, and the DUT is very slow anyway. And if it is bad, are they any more recent thoughts on alternatives? Do VISA handles behave the same way as TCP handles (ie. auto-close themselves upon exit of the VI that Opened them) ?
Message Edited by Mike Seibel on 11-28-2005 07:55 PM
Message Edited by Mike Seibel on 11-28-2005 08:00 PM
Message Edited by Mike Seibel on 11-28-2005 08:01 PM