Inter-Application Communication

[Jervin Justin]

» Inter-Application Communication

Overview

There are often cases where add-on developers will want to share data between LabVIEW and other applications. For example, you might be acquiring data in a LabVIEW application and want to send this data to another application to perform some post processing. Or you might want to trigger some action in LabVIEW from a different application. This functionality can be achieved using inter-process or inter-application communication.

For general information on inter-process communication, refer to:
Wikipedia: Inter-process communication
MSDN: Interprocess Communications (Windows Specific)

Example Software Packages

Consider a few example software packages that may be used in conjunction with LabVIEW. In some cases, 3rd party toolkits for LabVIEW exist for communicating between LabVIEW and these software packages.

The main reason that inter-process communication requires extra effort is because each application runs in its own protected memory space and its data is protected within this memory space. An application cannot access the memory of another application directly because they reside in their own memory spaces.

There are several architectures for inter-process communication, as well as several protocols in order to do this. This document highlights some of the common mechanisms that can be used with LabVIEW.

Inter-Application Communication Architectures

It is important to pick the right architecture depending on how and when your applications will need to communicate with each other. This list explains some of the more common architectures, and there are often overlaps between these:

Producer/Consumer Architecture

In this architecture, one application produces data while the other waits for data and ‘consumes’ it. For example, LabVIEW could be producing the data by reading from a data acquisition device, while an external application consumes it to run a report on the data, or vice versa.

Recommended Mechanisms

• File I/O
• File Mapping
• TCP/IP
• Command Line
• ActiveX
• .NET Remoting

Remote Procedure Architecture

This architecture is similar to calling a function that may return data, except that the function is run on a separate process. For instance, a LabVIEW application might at some point send a request to an external application, which will then do some processing and possibly return the data to the LabVIEW application. The reverse is also possible.

Recommended Mechanisms

• TCP/IP
• Command Line
• ActiveX
• .NET Remoting

Bi-Directional Communication Architecture

In this architecture, both applications can send commands to each other and can return data to each other.

Recommended Mechanisms

• TCP/IP
• ActiveX
• .NET Remoting

Shared Data/Object Architecture

In this architecture, rather than simply sending commands and returning data, both applications share the actual data through some sort of shared memory method, like File Mapping or .NET Remoting where both applications share the actual .NET object.

Recommended Mechanisms

• File I/O
• File Mapping
• ActiveX
• .NET Remoting

Inter-Application Communication Mechanisms

There are multiple mechanisms available in order to share data between multiple applications, and each has their strengths and limitations. We will concentrate on some of the more common mechanisms used:

• File I/O
• File MappingTCP/IP
• Command Line
• ActiveX
• .NET Remoting

File I/O

This is one of the simpler methods of transferring or sharing data between multiple processes where multiple applications share data by reading and writing to the same file on disk. While it has the benefit of being fairly easy to get started with and being cross platform, it is often slow due to slow disk access times. Also, care must be taken if multiple applications are writing to the shared file at the same time.

In many cases, a database can be used in place of the file.

Common use case:

A common use case for using File I/O to share data between applications is when one application uses the data after the first application is complete, as a port processing mechanism.

This mechanism is commonly used to share data, but not to send commands between applications.

Pros & Cons:

Pros:

• Easy to implement
• Cross Platform

Cons:

• Very slow
• Prone to race conditions

Examples/Resources:

For more information and examples on sharing data via File I/O from LabVIEW, refer to:

Inter-Application Communication: File I/O

File Mapping

File Mapping is very similar to File I/O on disk, but eliminates the slow disk access by holding the file in memory. This is how shared memory is implemented on Windows systems, unlike UNIX systems which implement an actual shared memory mechanism.

Common use case:

File Mapping is typically used when large amounts of data must be sent between applications where speed is important, however is does require some advanced programming.

This mechanism is commonly used to share data, but not to send commands between applications.

Pros & Cons:

Pros:

• Very fast – good to share large amounts of data quickly
• Actual data in memory is shared (No copy is made)

Cons:

• Prone to race conditions
• Have to call Windows SDK functions
• Not cross platform

Examples/Resources:

For general information on File Mapping in Windows, refer to:
MSDN: File Mapping

TCP

Communication over the TCP protocol is a very commonly used mechanism to pass data between multiple processes on a machine or even across computers on a network.

TCP communication uses a server-client architecture, where the server application opens a TCP port, and the client application connects to this port. Once a connection is made, the client and server names do not matter from a communication point of view as the communication can be bi-directional. Either application can listen for or send data.

Common use case:

TCP communication is typically used to send data from one application to another, and also to send commands from one application to another.

Pros & Cons:

Pros

• Fast
• Well documented and commonly used
• Easy to implement
• Cross Platform

Cons

• Data has to be ‘sent’, not shared (data is copied)
• Server must be able to open a TCP port
• Client and Server must agree on TCP port

Examples/Resources:

TCP/IP communication is very well documented and examples for most programming languages are commonly available on the internet .

For more information and examples on sharing data via TCP from LabVIEW, refer to:

Inter-Application Communication: TCP

Inter-Application Communication using TCP and .NET Remoting

Command Line

In most languages, applications can be written to accept command line arguments when they are launched.

Common use case:

While this method is severely limited by the fact that the data must be sent when the application is launched, it is commonly used to pass small pieces of data or commands when the application can be launched after the data is ready.

This mechanism is commonly used to send data or commands in a one-shot manner.

Pros & Cons:

Pros:

• Simple and straightforward

Cons:

• Arguments must be ready when application is launched
• Not suitable for large/complex data

Examples/Resources:

For more information and examples on sending commands or data via Command Line from LabVIEW, refer to:

Inter-Application Communication: Command Line

ActiveX

ActiveX is a framework that allows you to expose properties and methods of an application or library. One application can run as a server, which means that it exposes an ActiveX API to functions or properties of its objects. The other application runs as a client, connects to the ActiveX object and can call functions and get/set properties on this object directly.

ActiveX UI ‘controls’ can also be implemented that can be embedded in other applications.

Common use case:

ActiveX is commonly used to control one application from another. For instance, using the Microsoft Office ActiveX API, a LabVIEW application could embed and control an Excel spreadsheet on its front panel, or an external application could use VI Server (LabVIEW’s ActiveX server) to remotely load and execute a VI.

This mechanism can be used to send data from one application to another, and also to send commands and control one application from another.

Pros & Cons:

Pros:

• Fast
• Once ActiveX layer is implemented, easy to use (High level Vis/functions provided in LabVIEW, LabWindows/CVI and .NET)
• Direct access to external application’s data (objects)

Cons:

• Advanced programming to implement ActiveX API
• Not cross platform (Windows only)

Examples/Resources:

For more information on ActiveX in general, refer to:
Wikipedia: ActiveX

For more information and examples on controlling applications with ActiveX in LabVIEW using this method, refer to:

Inter-Application Communication: ActiveX

.NET Remoting

.NET Remoting is a framework that allows for inter-process communication using the .NET framework. Using .NET Remoting, we can share a .NET Object across multiple Application Domains (AppDomains), processes or even computers.

The way this works is that a reference to the shared or 'Remote' Object is made available to client applications through a .NET Remoting Server which registers and hosts the actual object.

Common use case:

.NET Remoting is commonly used to share a .NET object between multiple applications, and along with sharing the object, both applications can share the data of the object as well as call methods of the object. This is relatively easy to use from LabVIEW using the .NET block diagram nodes.

This mechanism creates a shared object, and so can be used to send data from one application to another, and also to send commands and control one application from another.

Pros & Cons:

Pros:

• Fast
• Once .NET Remoting layer is implemented, easy to use
• Direct access to external application’s data

Cons:

• Advanced programming to implement .NET Remoting layer
• Not cross platform (.NET Objects only)

Examples/Resources:

For general information on .NET Remoting, refer to:
MSDN: .NET Remoting Overview

For more information and examples on controlling applications with .NET Remoting in LabVIEW using this method, refer to:
Inter-Application Communication using TCP and .NET Remoting

Comparison of Communication Mechanisms

	File I/O	File Mapping	TCP	Command Line	ActiveX	.NET Remoting
Speed
Bi-Directional
Cross Platform
Across Computers?
Ease of Use

Child Documents:

Inter-Application Communication: File I/O

Inter-Application Communication: TCP

Inter-Application Communication: Command Line
Inter-Application Communication: ActiveX

Inter-Application Communication using TCP and .NET Remoting