LabVIEW
Question about two TCP connections established "by default" by LabVIEW EXE on Windows
Hi,
Does anyone know why a LabVIEW EXE on Windows establishes two TCP connections - over ports 61524 and 61525 - without being programmed to do so? What is the purpose of these connections, and can they be turned off/disabled?
Below is a screenshot of the TCPView tool in which you can see the two TCP connections of my EXE.
Background: I'm creating a LabVIEW Windows EXE that uses TCP communication to communicate with another EXE. At its lowest level the application uses the LabVIEW TCP primitives (TCP Open, TCP Read, TCP Write) to establish a connection and send/receive data. When testing the application, using TCPView I noticed that two TCP connections are established by the EXE as soon as it is launched. This is before the application establishes "its own" connection (the connection I programmed it to establish). When that additional connection is established I can see it in TCPView on a different port, in addition to the two "default" connections, as expected.
In summary I'm curious what the two "default" connections represent, and how they can be turned off. I would like the EXE to establish exactly one TCP connection.
LabVIEW Version: LabVIEW 2024 Q3 64-bit
OS Version: Windows 11 64-bit
Thanks!
My immediate thoughts are VI Server and Debug Server. I would have to do some digging to check that.
You could make sure you turned off debugging in the build specification for the application and see if that eliminates one or both of those connections.
Thanks. I too suspected VI Server. Is there a way to disable the TCP comms ability of VI server from built EXEs?
"Enable debugging" is already turned off in the build spec, as seen below.
Here are some keys I tend to add to my executables. I would need to give LabVIEW Wiki a visit to see what all of these do. But I suspect a couple of them will turn the debug server and VI server off. Most of these I just took from a default build ini file. The font keys I found and use due to font issues I had when going between XP and Windows 7. The return key action I found in LabVIEW.ini and it also worked in my executables.
server.app.propertiesEnabled = True
server.ole.enabled = True
server.tcp.paranoid = True
server.tcp.serviceName = "My Computer/VI Server"
server.vi.callsEnabled = True
server.vi.propertiesEnabled = True
DebugServerEnabled = False
DebugServerWaitOnLaunch = False
appFont = "Segoe UI" 13
dialogFont = "Segoe UI" 13
systemFont = "Segoe UI" 13
returnKeyAction = True
Thanks.
Initially the EXE was using the following INI settings:
I replaced those settings with the settings you kindly shared, as seen below:
This DID NOT change the behaviour - the two "default" TCP connections continued to be established immediately after launching the EXE, as seen below:
Notice that the Local Port and Remote Port indicate ports 64417 and 64418.
Restarting the EXE (without changing the INI file settings) resulted in the following:
Notice that the ports are now 50316 and 50317.
In short, changing the INI settings did not stop the connections from being established. A new behaviour was observed: The connections always use two consecutive port numbers, but those port numbers change (seemingly randomly) each time the EXE is launched.
Well it is not 2 connections but only one. TCPView shows the sockets (endpoints) the application has opened. And as you can see the endpoint remote and local address/port combination are simply exchanged. So it is in fact establishing a connection with itself. That the ports change between invocations means that they are dynamically allocated.
You do not define a specific port number for the VI Server port but instead a service name. A service name means that LabVIEW will allocate a socket on a dynamic port (specifying 0 as port number when creating the listener socket for the VI server which tells Windows to allocate any port that is still available). After that it registers the actually assigned port with the service name at the NI service locator. It seems that it for some reasons also establishes a connection to that service name, most likely for verification purposes that the listener socket works and the registration was successful. For some reasons it then lets that connection open, not quite sure why.
You could try to specify an explicit port number in the VI Server settings for your project target specification or disable VI Server altogether to see if that makes any change.
"Well it is not 2 connections but only one. TCPView shows the sockets (endpoints) the application has opened. And as you can see the endpoint remote and local address/port combination are simply exchanged. So it is in fact establishing a connection with itself. That the ports change between invocations means that they are dynamically allocated." - Thanks, that all makes sense.
The first two screenshots below show the existing VI Server configuration of the My Computer target:
As can be seen, the TCP/IP tickbox was already unticked. The Machine Access, Exported VIs and User Access lists were empty.
I unticked the four tickboxes in the Accessible Server Resources category and rebuilt the EXE. This did not change the behaviour - the connection is still present - as seen below.
In short, I still don't know what is the purpose of that connection, or how to prevent it from occurring. It's not a showstopper by any means - it's mostly a curiosity - but I wish that LabVIEW by default did not open any connections, and if it did, it would explain what the connection is doing and how to disable it.
All the EXEs discussed in this thread so far were built in LabVIEW 2024 Q3 64-bit. I wonder if the same behaviour occurs in other versions.
