problem closing a socket connection

[jcrooke]

I am communicating with a Rabbit Semiconductor rcm2100 through a TCP/IP socket connection. The rabbit is running a server and my LV code is supposed to connect to it, and send and receive data through this connection. The vi in question works fine the first time I run it. But I can't run the vi again until I restart LV (6.1 by the way).

When I start the vi, it opens a socket connection to the rabbit board. The server accepts the connection and correctly processes commands from the LV vi and correctly sends responses back to the vi. In the exit procedure for the vi, I close the socket and then exit the vi. The rabbit board correctly acknowledges that the connection was closed by the server and reinitializes to a "liste
n" state in which it waits for a connection from another client. When I restart the vi, it cannot connect, returning the error

"Error 60 occurred at TCP Open Connection in rabitModule.vi->testRabbitModule.vi.

Possible reasons:

LabVIEW: The specified network address is currently in use."

I can successfully connect to the rabbit using telnet, but my vi won't connect until I restart LV.

Please, help me understand why this happens and what I can do to fix this problem? Thanks.

[jcrooke]

This is a patch but not a fix.

I found that I could increment the port number and reconnect. Each time I try to connect to the rabbit, I first try on port 2001. If it fails, I increment the port number and try again. I repeat this until I can connect.

I found that, after some unmeasured time on the order of a few minutes, the 2001 port is freed again for establishing connections. LV seems to be reserving the port until some timeout. Since disconnects and reconnects are infrequent in my application, this patch may work, but I would still like to know the correct solution rather than leave resources in temporary limbo.

jayme

[SVences]

Hello �

The behavior you are seeing - after some time, the 2001 port being freed again for establishing connections - is expected behavior. Whenever a TCP port is closed, the OS keeps the port in a state known as "TIMED_WAIT" for some period of time. This period of time is OS-specific (it can go up to a minute or two in some OSes) and, as far as I know, not changeable. As long as the port (port 2001, in this case) is still in TIMED_WAIT state, no new listeners will be able to start on that port. Once the OS releases port 2001 from TIMED_WAIT, everything begins working properly again.

So, you need to find out how long your OS keeps the ports in TIMED_WAIT state after closing a TCP connection and add a wait in your program after the closing or something li
ke that to guarantee that if you are to run the program immediately after, then it works.

S Vences
Applications Engineer
National Instruments

[jcrooke]

Thanks for the confirmation. That explanation is consistent with every test I have done. -jayme

[Lasun1432]

So what can be a possible solution to this if there are multiple servers (PLCs) a VI is accessing in a process based machine and in case any one connection breaks for some reason, a minute's time will result in loss of thousands of dollars.

[billko]

---

@Lasun1432 wrote:

So what can be a possible solution to this if there are multiple servers (PLCs) a VI is accessing in a process based machine and in case any one connection breaks for some reason, a minute's time will result in loss of thousands of dollars.

---

If it's truly that critical, money might be better spent preventing a disconnect, rather than trying to deal with the consequences of one.

[Mark_Yedinak]

In the code the OP posted many years ago, the mistake they were doing was to use a hardcoded value for the local port. There is rarely ever a need to use a predefined value for the local port on the client side of a connection. Leave this input unwired and you should be able to reconnect instantly. Obviously you have the overhead of establishing the new connection but you will not have to wait for the TCP TIME_WAIT to expire.