Question about two TCP connections established "by default" by LabVIEW EXE on Windows

[Petru_Tarabuta]

Thanks. It was the right link.

I created a new project using the NI QMH template that ships with LabVIEW, did not make any changes, and built the EXE.

I launched the EXE with and without the NI Service Locator service running (I used the Windows Services window to stop the service between runs). The behaviour did not change. The EXE still establishes a connection to itself, and it does so even before the front panel of Main.vi is displayed to the user (I can see the connection appear in TCPView a fraction of a second before the EXE displays any window).

Hmm... does anyone else feel slightly alarmed that LabVIEW creates what seems to be an unnecessary and/or obscure connection, does not inform us of this, and makes it hard (if at all possible) to disable this behaviour?

[rolfk]

---

@Petru_Tarabuta wrote:

Hmm... does anyone else feel slightly alarmed that LabVIEW creates what seems to be an unnecessary and/or obscure connection, does not inform us of this, and makes it hard (if at all possible) to disable this behaviour?

---

Alarmed? It's a localhost connection to itself! If you had said annoyed then I could agree but this is not really able to do anything bad including phoning home. So alarmed would seem quite paranoid to me.

[Petru_Tarabuta]

Ok, if there's no security risk then maybe "alarmed" is too strong of a word.

But IMO slightly annoying or disconcerting still applies. Especially the fact that there doesn't seem to be a clear explanation of what the connection is actually doing (why is it necessary), and no way to disable it.

I would be happy if by default the EXE contained some "bloat functionality" if I was able to understand and disable it if so desired.

In the KB article that IlluminatedG kindly shared, the only paragraph resembling an explanation of what the connection is actually doing is: "The NI Service Locator facilitates communication between National Instruments support programs and services, such as the NI Example Finder and RT Proxy. These programs and services use local dynamic TCP ports to communicate with each other. The NI Service Locator manages these dynamic ports." . This explanation, while useful, is vague. What connections are created by default? What does each connection do? How can they be disabled?

I guess what bothers me is that this extra TCP connection goes against the general principles of minimalism and understandability. I don't want my app to contain extra functionality that I didn't ask for and can't explain to myself or others (due to seeming lack of specific documentation).

[rolfk]

The Service Locater may be somehow related but it is NOT this connection. The Service Locater is a separate process. Initially (LabVIEW 5 or 6 or so) it used to be a VI that was launched in stealth mode (VI had special flags that made it invisible to normal LabVIEW functions enumerating loaded VIs) in LabVIEW and for the Mac this was kept like that for quite some more time but ca LabVIEW 6 or 7 this was moved into an OS service on Windows. It's a fairly small HTTP server that only understands a few commands such as for registering/removing a service and querying it, and also getting a dump to list all currently known services. It is basically a simple key value pair list, with the key being the name and the value the port number and a means to query that.

Somewhere around 2009 NI decided to integrate this service into the NI Web Server but eventually with 2013 reversed that decision and made it a separate Windows service again. It allows NI software not to need to have so called well known fixed port numbers. Instead any possible NI service starts up a TCP listener or an UDP endpoint with a dynamic port and then registers that port number under a "well known" name with the Service Locator on its own machine. Anyone needing that service can then query for the "well known" name on the target machine, and then create a connection to it. This way only one single fixed port has to be reserved for NI software, namely the NI Service Locator port. This functionality was also integrated into the LabVIEW network nodes where Create Listener got the "service name" input and if this is not an empty string LabVIEW will automatically register the resulting port with the NI Service Locator. The TCP Connect also got a "service name" input where you can either wire an integer port number or a service name string and in the case of a string LabVIEW will first query the NI Service Locator for that name and if successful use the resulting port number to create a socket to connect to the server.

Connections related to service discovery would be always temporary. LabVIEW or whatever other NI software either creates a TCP listener or UDP endpoint and then opens a connection to register it and then closes that connection again, just as any simple HTTP communication always has worked. HTTP originally always closed every connection right away again after receiving a response, but that proofed to slow down the transmission of complex web pages significantly and it then learned to do keep alive protocols and such.

This is definitely something else. And the hint about Help Server or potentially Example Finder is my personal popular guess for this although that are edit time tools so not sure how that would fit into an executable. It's mysterious and indeed a bit concerning that there seems no way to find out what it is, but definitely not alarming. My gripe with it is mainly that I'm usually quite diligent about avoiding unnecessary waste of resources and as long as I don't know what this connection is for, I consider it unnecessary and the ports it opens and keeps occupied an unnecessary resource waste.

Anyone seeing an active thread in this is definitely somehow a bit in paranoia land but there are definitely industries that tend to be paranoid by definition 😁.

[Petru_Tarabuta]

Thanks for the information.

"It's mysterious and indeed a bit concerning that there seems no way to find out what it is, but definitely not alarming. My gripe with it is mainly that I'm usually quite diligent about avoiding unnecessary waste of resources and as long as I don't know what this connection is for, I consider it unnecessary and the ports it opens and keeps occupied an unnecessary resource waste." - fully agree.