» Inter-Application Communication » TCP & .NET Remoting Example

Overview

There are often cases where add-on developers will want to communicate from LabVIEW to a separately running application. There are several methods available to communicate between two applications. This example shows how to do this using two common methods, TCP/IP and .NET Remoting, and compares them.

Server Application

The server application acts as a 3^rd party application that hosts an object that has data (variables) and can perform analysis on the data (functions).

The server then exposes this object to other applications using both TCP/IP and .NET Remoting.

Hosted Object

The hosted object on the server application exposes the following:

TCP Server

The server application opens a TCP port and listens for commands from client applications that connect to this TCP port. The server ‘exposes’ functions of the hosted object by parsing the commands that come in from TCP clients and calling the appropriate function on the object.

.NET Remoting

The hosted object on the server application is made available to client applications by implementing the object as a .NET Remoting object. This means that other applications can get a reference to this hosted object and can directly call functions and use properties of the hosted class.

TCP Client Application

The TCP Client application is written in LabVIEW and uses the standard TCP VIs that ship with LabVIEW to connect to and communicate with the hosted object on the server application.

Any interaction requires the command to be converted to a string and then sent via TCP to the server which will then decode/parse the string to determine what action needs to be taken.

.NET Remoting Client Application

The .NET Remoting Client application is written in LabVIEW and obtains a .NET reference to the hosted object by calling a static method on a utility assembly (provided). Once a reference is obtained, the LabVIEW client application can call functions and use properties of the hosted object directly by using the standard .NET Property nodes and Invoke nodes.

Caveats

Bi-directional Communication with TCP:

This example doesn’t implement a true bi-directional communication scheme. Communication is always initiated by the client application and the server may send data back as a response.

In order to perform true bi-directional communication both applications need to be listening for commands, while being ready to send commands whenever they chose. The TCP Read commands we use are synchronous blocking calls, and so if we wanted to interrupt the Read in order to Write, we’d have to use some sort of polling Read (possibly using timeouts) instead, and this wouldn’t be as straightforward.

An alternative approach would be to open two ports, and have one port dedicated to incoming communication and the other port dedicated to outgoing communication.

Bi-directional Communication & Events with .NET Remoting:

This example doesn’t implement a true bi-directional communication scheme. Communication is always initiated by the client application and the server may send data back as a response.

In typical .NET Remoting applications, the shared object can communicate to the clients using event notifications. The client applications can register for events and assign event handlers to be called when the shared object throws an event. While LabVIEW can register for events on regular .NET objects, .NET Remoting objects use a proxy object, and LabVIEW does not actually catch events thrown by the shared object.

A possible approach would be to write a wrapper object that catches and re-throws the event, and register for the re-thrown event from LabVIEW. This is described here:
NI Discussion Forums: Is it possible to derive a LabVIEW VI from a .NET class?

Instructions

1. Start .NET Remoting and TCP Server Application:
   <Example>\DNRemotingAndTCPServerApplication\bin\Debug\DNRemotingAndTCPServerApplication.exe
2. This will launch both the TCP Server as well as the .NET Remoting hosted object
3. Launch either TCP Client or .NET Remoting Client (or both):
   TCP Client: <Example>\TCP Client\TCP Client Application.vi
   .NET Remoting Client: <Example>\DNRemoting Client\DNRemoting Client Application.vi
4. Changing the values or clicking the buttons on the client application will send the appropriate messages or call the appropriate functions on the server and will update the hosted object accordingly.

Source Code Hierarchy

• <Examples>\DNRemotingAndTCPServerApplication
  Source code for the server application. Contains 3 main classes:     
  • DNRemotingAndTCPServerApplication
  • TCPServer
  • DNRemotingServer
• <Examples>\DNRemotingRemoteObject
  Source code for the hosted (shared) .NET Remoting object and utility functions to get a reference to the remote object. Contains 2 main classes:     
  • DNRemoteObject: Hosted (shared) .NET Remoting object
  • RemotingLibrary: Contains static utility function to get a reference to the remote object
• <Examples>\TCP Client
  LabVIEW VI source code for the TCP client application
• <Examples>\DNRemoting Client
  LabVIEW VI source code for the .NET Remoting client application

Additional Resources:

TCP:
LabVIEW Help: TCP VI and Functions
LabVIEW Help: Creating a TCP Client

Inter-Application Communication: TCP
.NET Remoting:
Wikipedia: .NET Remoting
MSDN: .NET Remoting Overview
Community Example: Calling .NET Assemblies from LabVIEW