Linked Network Actor uses network streams to create a peer-to-peer link between two already-launched actors. This link is a short circuit of the usual Actor communication tree. In the intended use case, the actors reside in separate application instances, such as a host application running on a desktop computer and a target application running on a real-time system. Linked Network Actor is suitable for both continuous and intermittent connections, such as a host which periodically connects to its RT target for monitoring.
To use this class, launch the two actors you wish to link and have each of them launch a nested actor of this class. Decide which of your actors will initiate the connection, and have it send the Connect message to its Linked Network Actor. Either actor can send the Disconnect message to break the connection. Linked Network Actor sends an Update Status Message to its caller whenever its connection status changes. This is an abstract message; the caller is expected to provide a concrete implementation when first launching the Linked Network Actor.
Use Transmit Network Message to send messages between the linked actors. Create the message you wish to send, and use accessor methods to set its attributes. Wire this message to the message input of Send Transmit Network Message. The local Linked Network Actor will send the message to the remote Linked Network Actor, which will then forward it to its caller. Note that sending a Transmit Network Message to a Linked Network Actor that is not connected will result in an error.
The package will be installed in <user.lib>\Actors\Linked Network Actor. An example VI, Linked Network Actor Test.vi, will be installed in the folder <LabVIEW>\examples\Actors\Linked Network Actor.
This version of Linked Network Actor does not cover all use cases. Specifically:
Future versions of this actor may address these issues.
This is an EXPERIMENTAL_FORK compatible with AF 4.0.
Edit: Updated to version 1.01.
Edit 9/27/13: Updated to version 1.2.
1) This version corrects a problem that occurs if a target running a Linked Network Actor is rebooted or otherwise disrupted while the Linked Network Actor is connected to a remote Linked Network Actor. In this situation, the remote Linked Network Actor would persist in a connected state. The next attempt to connect to the remote Linked Network Actor would fail, and the local Linked Network Actor would stop and return a timeout error. The attempt would, however, reset the remote Linked Network Actor, and subsequent attempts to connect would succeed.
This version changes the error handling behavior of the Linked Network Actor. The Linked Network Actor will now report timeout errors (Error -314004) without terminating. This allows the caller to attempt to retry the connection without having to restart the Linked Network Actor.
The LNA will also report, without terminating, if the endpoint to which you wish to connect does not exist (Error -314100), or already exists (-314101).
2) At the request of users, we have also changed the name of the abstract message "Update Status Msg" to "LNA Connection Status Msg". This should make the abstract message easier to find when building concrete implementations, and shoudl avoid name conflicts with future actors.
3) Certain methods in this version of the Linked Network Actor have been given community scope. If you wish to use this version to communicate with CompactRIO and other VxWorks targets, you must install the LabVIEW 2012 Real-Time Module f1 patch, available free from National Instruments.
4) If you try to send a message to a remote LNA, and the transmission generates an error, the local LNA will return the transmitted message and the associated error to its caller, using the abstract message "LNA Return Message Msg." This return message will have high priority. This will not create an error condition locally, so the LNA will not shut down.
Update by niACS (8/24/15): I've had a fair number of requests to create a version of the LNA that uses TCP/IP. As I was looking into the best way to do that, I realized that I needed to change the architecture of the LNA. I've been applying the Single Responsibility Principle to the LNA, breaking it up into protocol, message pipe management, and connection management components. I've implemented the first two components here:
The last piece, connection management, requires different solutions depending on your problem statement. There is definitely a role for the single connection, always available object that is the LNA. My plan is to implement such a solution that is based on Network Endpoint Actors. Watch this space.