Two apps on the same Windows PC - are network published shared variables the best way to communicate between them?

[AnthonV]

Hi, we have two built LabVIEW apps running on the same Windows PC.  We want to communicate between them, at about a rate of 1 message every second.  Is using Network Published shared variables the best way? 

One other related question - why does Network Published shared variable stop working when I turn on my company VPN on the computer?

"Deploying Networking.lvlib\\10.139.28.143\Networking deployment failed (error: -1967357949, OS and Network Services: (Hex 0x8ABC8003) Unable to query Measurement & Automation Explorer for the Network Variable Engine. Make sure the Network Variable Engine (which installs support for network-published shared variables) exists on the RT target and check that the network connection is valid.)."

[rolfk]

Best is very subjective here! Best in terms of ease of development or best in terms of full control of what happens?

I personally always opt for the second option which is why I use explicit self programmed TCP/IP communication for that. That’s no easy task however and you are bound to experiment in the beginning and try to work around typical networking communication issues. Achieving a robust communication infrastructure in that way is not an easy feat.

Shared Variables are at the other end of the spectrum. Mostly just configuration work and then the Deploy switch and crossing your fingers that it works, if it does that’s great, if it doesn’t it’s bad luck and you can try to fiddle with obscure Windows network configuration settings in the registry to get it to work, except that this is mostly a blind flight through a narrow canyon. No idea when you take the right turn or smash in one of the canyon walls.

Something of a middle ground might be using remote VI server. The low level protocol is taken care of for you and it is a reasonably straightforward TCP/IP implementation without the undocumented service announcement and discovery elements of shared variables that your VPN apparently manages to get into confusion by changing the Windows network routing tables. Since we don’t really know how they work it’s hard to debug and your VPN provider likely won’t feel inclined to help you either, despite that it might be something they do that is possibly a bit overzealous or maybe simply a bug.

They also might feel that their manipulations of the routing tables are an important trade secret that when spilled to the public could devaluate their security. That would be however nonsense since security through obscurity is no security at all.

[AnthonV]

Always a pleasure to here your opinions Rolf. 

Yes up till now we usually implement our own TCP/IP connection with handshaking, dropped connection recovery etc.  We have been avoiding shared variables but have been wondering recently if we are unnecessarily stuck in the 2000's and should move on to the 2020's. Everything about Shared Variables seemed so easy until we switched on the VPN.  Also wondering about the security aspects. 

Let's hear if there any other comments on the topic.  Re the VPN its probably some firewall setting. 

[Bob_Schor]

I replied that I've "abandonded" Network Shared Variables about a half-dozen times since they were introduced (I keep optimistically saying "it will work for this simple application", then spend a week or so tracking down the "mysterious failures").

But then I noticed you said "Two apps on the same Windows PC", and mentioned a message rate of something like once a second.  Since you are having problems with VPN, what about a solution that doesn't involve the network at all?

If latency isn't a problem (say polling for a message 10 times a second), a "crude but effective" communication might be to simply write a File with the message inside.  The intended recipient does a "Read Text File" using the agreed-upon Path.  If the file exists (and hence there's a message), the "No Error" case closes, then deletes, the file, returning a "True" Boolean (saying "Message Received" and the Message.  This seems to take about half a millisecond on my laptop.  If there is no Message, the Read will throw an Error, which you clear and return an Empty Message and a Boolean False -- this takes about a tenth of a millisecond.

This can be easily extended to multiple interacting routines, or multiple independent Messages (each tagged with a unique name).

There's probably a LabVIEW property to do this via "In Memory" files that I haven't explored, but if not, this is "quick and cheap".

Bob Schor

[AnthonV]

Thanks Bob, as we are using solid state drives it probably would be a very reasonable method to use files as the communication medium. Even just the existence of a file could be message in itself. I wonder if RAM-disks are still a thing?

Ok so we have NPSV, VI server, raw TCP/IP and files on disk, as the options so far.  Although the file method is probably not the most elegant, it would be immune to unexpected changes to the Windows Firewall by domain policy updates. 

[crossrulz]

For completeness sake, there are also network streams.

Personally, I would use TCP using "localhost" as the target address.

[rolfk]

To be really complete you should also consider memory mapped files. You need to access the Windows API for them (you are running under Windows, right?) but there have been some VI libraries around that do most of that work already.

Considering that you have solid state disks it may be actually beneficial to use memory mapped files rather than real files on the disk as that would reduce the number of read and write operations to the disk.

If this is rather under Linux instead of Windows, pipes could be another way to communicate. LabVIEW for Linux has pipe support out of the box.

I personally keep coming back to TCP/IP communication despite the possibility of using pipes or memory mapping, since they seemlessly support the distribution to different computers/controllers without anything else than reconfiguring the remote address in one or both of the applications.

[AnthonV]

Thank you for all the feedback.  I'll be staying with TCP/IP messaging for now but I'm sure other readers may decide that one of the other options is the best solution for their situation. Thus feel free to post more pros and cons on this thread.

It's worth mentioning this resource where someone went to a lot of trouble benchmarking Shared Variables compared to other methods:

https://www.ni.com/en-za/support/documentation/supplemental/06/using-the-labview-shared-variable.htm...

[Bob_Schor]

---

@AnthonV wrote:

It's worth mentioning this resource where someone went to a lot of trouble benchmarking Shared Variables compared to other methods:

https://www.ni.com/en-za/support/documentation/supplemental/06/using-the-labview-shared-variable.htm...

---

It is also worth mentioning that the benchmarks were done using LabVIEW 8.2 and 8.5, more than a decade old, running on operating systems that have been "retired" for about a decade.  Use several "grains of salt" when reading ...

Bob Schor