bug: tcp open ignores timeout

[Yamaeda]

If it cannot connect it gives error 56: timeout after ~20 secs regardless of timeout input.

LV 2010 SP1 

/Y 

[MarcoMauri]

It seems ok to me.

I've tried with this:

regards,

Marco

[Yamaeda]

Correction: It ignores values larger than 20-ish seconds, it then timeouts at ~20 secs. 🙂

The default 60000 timeouts at 20 secs, changing to 120000 makes no difference. 

/Y 

[MarcoMauri]

A quick check confirming what you say:

-1 doesn't wait forever. Stops at 20s.

Regards,

Marco

[MarcoMauri · Accepted solution]

Maybe here's the reason:

http://digital.ni.com/public.nsf/allkb/68A461BD68ECB827862565380068CA23

[banksey255]

I know this is an old post, but the link in the accepted answer is broken. Does anyone know what information it had?

I am experiencing potentially a similar problem where I set a TCP Open Connection timeout of 200ms, and then if I specify a remote IP and port number, then it takes 200 ms to timeout, as expected, however if I specify a remote IP and service name, then it takes 21 seconds to timeout. My first thought is that it is a bug in LabVIEW 2019 SP1, like the original post.

[rolfk]

Is this about a address not even present on the network? Then it could be related to this: https://forums.ni.com/t5/LabVIEW/TCP-Open-Connection-timeouts-too-soon/td-p/4277672

As to the difference with using a port number versus using a service name:

A port number directly attempts to connect a socket to the remote address and port. A service name attempts to contact the NI service locator daemon (a special NI service) on the target machine to ask it what port number the service name responds too. If it receives a valid response from the NI service locator it uses the received port number to attempt to establish a connection to the target listener.

This implicates a few things:

1) There has to be an NI service locator running on the remote computer.

2) The application at the other side needs to have registered its service name with the NI service locator. This generally only is true if you have on the other side another LabVIEW based application AND wrote it in such a way that it passes a service name to the Create Listener function, so that that function registers the resulting listener port number at the local service locator.

It also means that there are in fact many more network operations needed before your TCP Connect function even can attempt to connect a socket to the actual listener on the target machine. With a timeout of 200 ms, that never could even remotely work in a reliable way unless your target application is on the same machine as your client and even then there might be trouble. So LabVIEW correctly uses some higher timeouts internally to avoid premature abortion.

Even if you use directly a port number, 200 ms is rather on the short side if your devices are not all located on the same subnet.

[banksey255]

Thanks, Rolf. No, it's not related to the address not being present, and yes, it is a LabVIEW application running on the remote computer, and in my case the remote computer is directly connected via a cross over cable so is on the same subnet.

The solution I've developed in response is to avoid using a service name with TCP Open Connection by instead querying the NI Service Locator on port 3580 to obtain the port number associated with the service name, and then using TCP Open Connection with that port number. This is very fast (at least relative to the 21 seconds).

[rolfk]

There is a VI library in LabVIEW that implements the very basic HTTP protocol for the NI Service Locator at <vi.lib>\Utility\ServLocInterface.llb. It has specific methods such as SL_Get Port.vi to request the port number for a specific service name. It is more convenient and efficient since the Service Locator implements specific url requests for these methods rather than having to resort to dumpbin? and parsing out the service yourself.