Using VI Server without triggering firewall

[josborne]

Hello experts.  I have a challenge for you:

I have two LabVIEW-built executables running on the same Windows computer.  Let's call them ServerApp and ClientApp.  I want ClientApp to be able to read/write control values on a VI that is running on ServerApp.  I can get this to work using VI Server.  Its easy.  Here is basic code I use:

And here is the .ini file for ServerApp:

[medicollector_viewer]
server.vi.callsEnabled = True
server.app.propertiesEnabled=True
server.tcp.enabled=True
server.tcp.port=0
server.tcp.access="-*;+localhost;"
server.tcp.serviceName="MyServiceName"
server.vi.propertiesEnabled=True
DebugServerEnabled=False

Question:

The first time I try to do this on a new computer, the Windows Firewall pops up a warning and asks for permission.  I am guessing this is because VI Server is using TCP.  But is there any way to avoid this?  I am only going to do this from the localcomputer, so I tried to restrict access to everybody excpt the localhost using this string: in the .ini file using:

server.tcp.access="-*;+localhost;"

But that doesn't help.  And I am very confused by all the other keys in the .ini file. 

Is there any way to make this appear "safe" to the firewall?  Such as a way to use VI Server with the ActiveX protocol?  It appears HERE that this is somehow possible?

[Ben]

I wonder if this is more an issue with the firewall settings than LV.

When I build a new exe and run it for the first time, I get a message about the virus checker wanting to scan the exe before it will run.

Ben 

[josborne]

Just to add to this:

The firewall does not get triggered if you disable VI Server by doing this:

server.tcp.enabled=False

My guess is that this is because VI Server launches and attempts to open a TCP listening port.  And my firewall (using Default Win7 settings) considers this risky, even though it will only allow connects on localhost.

So I am guessing my only workaround is to use something else besides TCP?

Does anybody have a concrete example of how to use VI Server through ActiveX?

[playerm1]

When you open the application reference to the ServerApp (very first function), you may want to try specifying the specific port in use by VI Server for that ServerApp (3363 by default).  When you specify a string (service name) instead of a U16 integer (port), I'm pretty sure LabVIEW will need to interact with the separate background process "NI Service Locator".  Bypassing the use of NI Service Locator may simplify tracking down the firewall/permissions issue that you're seeing.

[josborne]

Playerm1 had a good idea.  But it didn't help.  I tried using a fixed port number, but firewall kept showing warnings.

No matter what I do, if I set server.tcp.enabled=True then the firewall (w/ default Windows settings) will issue a warning.  This makes sense, I guess, because its probably opening a port to listen for connections.

So I wonder if I can use Active-X instead....    I just don't know how.

[billko]

NI installers get around this by telling the user to say okay to the popup if it comes up. 

[rolfk]

If a firewall is enabled that deserves that name, it will always popup a dialog to prompt you to allow it to access the network as soon as that application tries to open any network sockket, be it a listen socket to initiate a server or a client socket to initiate a connection to a server. 

Replacing the TCP interface with Active X doesn’t solve much but simply creates at least one more problem. For one the Active X interface in LabVIEW is very old and hasn’t been updated to support any of the many additions to the VI Server hierarchy that were added since the initial introduction in LabVIEW 6.x or thereabout. So many things are simply not possible through the Active X Automation Server interface in LabVIEW. Also adding Active X to your program will always create trouble in the long run, it’s an old Windoews legacy technology only a few years more modern than DDE.

Still if you absolutely have to do it you will need to designate one of your applications as Active X Server by enabling the according settings in the build configuration and then use in the other application Active X nodes to open a connection to the server and then using Active X nodes to acces the Active X server interface of LabVIEW. There is a typelibrary .tlb in the resource folder in LabVIEW that describes the interface, when you point the Active X refnum at that file you should get all the possible classes (I believe only LabVIEW Application and LabVIEW Instrument and the supported methods and properties for each) but don’t expect even remotely the same number of methods and properties than what a modern LabVIEW version supports in the VI server interface!

Personally I would rather investigate a possibility to add a firewall rule during application installation and then create an Installer with this added script call or batch file execution. Since the Installer is normally executed with elevated rights already, such a tool would be called with the same rights and even could access priviliged resources. At least for the Windows firewall it’s likely a registry entry somewhere and that could possibly even be done with the registry settings that you can add in the biuld configuration for a LabVIEW application installer.