From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
TCP Open Connection using Service Name hangs LV 2014
@NordicViking wrote:
Hey Steven,
However, I do think that something so fundamenal as TCP/IP-VIs really should be relyable and "bomb-proof"; so I think, i would be in the interest of NI, too, to have this nasty bug (which could lead to total programm-freeze) fixed.
The only way to have software bomb-proof is to not run it at all! A less extreme way is to test it and retest it a few thousand times on a specific setup and never ever again change anything on it after that. That's the reality and nothing anyone can do about it.
When this feature was added to the TCP/IP VI's, many people would have given you a blank stare if you asked them about what firewall they use with possibly the question: "What is a firewall? or possibly "I don't have a firewall in my house!"
Modern computer firewalls do all kinds of fancy stuff, digging deep into the network stack and modifying its behavior in ways nobody would have thought of 10 years ago, and just about anyone would have declared a person crazy, if they had suggested something like that.
And a firewall is supposed to work seamlessly, which means it does not return an error when you attempt to do something that it feels is not legitimate according to its rules, but it generally simply makes the underlying network stack function behave as if the desired address or function is not present, which will result in lengthy and usually inside the stack hardwired timeouts. Generally nothing LabVIEW could even detect, since it's desired behavior that a malware application can NOT detect that it is blocked by a firewall but instead just sits there waiting for the connection to succeed, which will never happen if the firewall works correctly. And if a malware shouldn't be able to detect that it is blocked by a firewall, LabVIEW can't detect it either.
The service lookup relies on the fact that a local service locater deamon (a Windows service on a Windows machine) on the target machine is installed, enabled and running and that it has network access rights. When you use the Create Listener function with a service name, it creates a socket bound to an arbitrary port and then registers that service name and according port number with the service locater deamon on its own machine.
When you then use TCP Open to connect to a Listener by service name, this will contact the service locater service on the target IP address and query for the port number that service has registered. If successful it will connect to the port number that query returned and return. If the service name could not be found it will return with an error. But there is a third option, that the firewall on the server machine (or possibly your own firewall on your own machine considers this an illegal connection attempt and it simply makes the connection request to the NI Service Locater only return after a HUGE delay, with an error indicating that the remote application is not reachable. Now LabVIEW could simply return with that error, or considering that TCP/IP can sometimes flake out, retry another time to connect to that service! And now you have a problem. You either make some legitimate retry attempts (legitimate because connection requests can sometimes timeout and will succeed if you try another time) and run into the problem that when this failure is caused by a firewall you run into seemingly indefinite timeouts, or you abort after the first failure and return with a timeout error and let the application developer deal with the decision to retry on error or not. But even in this second case the inherent timeout caused by the firewall on the first call already might be in the order of minutes anyways.
So lets look how the NI Service Locater service works: First you have the NI Service Locator deamon running on the machine that runs the TCP IP Server which registers itself under a name. This usually works, since a local process usually has the right to connect to a local TCP/IP port, so the TCP Create Listener function can normally connect to the NI Service Locator service to register itself.
Now for the client the things are a bit more complicated. This client needs to have the right to make a connection to the target machine and specifically on TCP port number 3580, which is the NI Service Locator port number. The protocol it uses is HTTP but it obviously can't use the port number 80, as that is to likely to conflict with another user installed service or application that wants to behave as HTTP server. But strictly configured firewalls, especially on the computer that runs the Service Locator will often block incoming connections to TCP/IP endpoints that are not well known TCP port numbers and/or considered unsafe such as port 21 for FTP for instance.
There is also the chance that even the client computer will restrict outgoing connections to port numbers it does not recognize as well known services, possibly also coupled with stateful protocol inspection to make sure that there is really the expected protocol transferred over the wire, that matches with the port number.
The real problem is not that LabVIEW doesn't know how to work around a firewall, but that you need to understand what TCP ports are involved and to configure your firewalls on the server machine and possibly your client machine, to allow for these ports to be accessed.
