Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Deployment in a network

Hello,

I started learning the actor framework and made some progress. My next task is about controlling and grabbing data from two cDAQ systems connected via Ethernet and two GigE cameras plus UI and data processing on another machine. So this would be a case for Network Endpoint Actors... I think.

Now I'm trying to understand the example that comes with it, i.e. the two chat windows communicating either through network streams or TCP/IP directly. It runs fine on one machine.

What I can't figure out is, how to modify/deploy the example with two computers. Can I just copy the whole project to another machine and modify the launcher?

How would I approach a project with a larger number of clients? It seems a bit silly to copy a bunch of irrelevant stuff, like UI and everything else contained in the project, to, say, a DAQ machine.

Maybe it's obvious, but I don't get it... Thanks in advance!

0 Kudos
Message 1 of 4
(3,344 Views)

The chat window example is just that - an example.  Study it to see how nested endpoints work.  You won't use anything from Chat Window.lvlib in your actual code.

For your project, you'll want to create a remote proxy actor.  This actor has all of the messages you will need to send between your two computers, but the methods those messages invoke are virtual, i.e.e they are dynamic dispatch methods that don't have any code on their block diagrams.

Let's assume your two computers are called Host and Target.

Create a child of your remote proxy for Target, and another one for Host.  These actors form the interface between your two systems.  Have the Target-side proxy launch a nested endpoint with a listener protocol (TCP/IP or Network Stream, your choice), and have the Host-side proxy launch an endpoint with an initator protocol. 

Say you have a message that you send from your Target to your Host called Update Fan Msg.  This message is part of the remote proxy actor, and it invokes a method called Update Fan.vi.  The Target-side proxy will override Update Fan.vi to forward the message to its remote counterpart, as shown here:

Forward Message.png

The Host-side proxy will provide an override of Update Fan that does whatever your host would do with that data.  It might look like this:

Receive message.png

In this case, we generate a user event to update a front panel indicator.

Repeat for the rest of the messages you need to support.

0 Kudos
Message 2 of 4
(3,065 Views)

Thanks, now the term proxy makes more sense to me.

So all I have to share between the host project and the target project is the proxy actor? Which means, for each target that is connected to the host I have to create a separate proxy actor (assuming I want to send a different set of messages to/from each target).

But what about this scenario: I have a target machine which runs the fan and a large set of other tasks as well. For each task there is an actor. I can imagine that the set of messages through the proxy actor could get huge and confusing. So, does it make sense to create a proxy for each task to keep things organized? I guess this is more like a best practice question...

0 Kudos
Message 3 of 4
(3,065 Views)

pktl2k wrote:

Thanks, now the term proxy makes more sense to me.

A remote proxy, specifically.  There are other kinds.

So all I have to share between the host project and the target project is the proxy actor? Which means, for each target that is connected to the host I have to create a separate proxy actor (assuming I want to send a different set of messages to/from each target).

Correct.  I should point out that the shared parent actor (with the messages and virtual methods) will be locked when both the host and target projects are open, but the two child actors will not be.  That's why the host- or target-specific code goes in the child actors.

But what about this scenario: I have a target machine which runs the fan and a large set of other tasks as well. For each task there is an actor. I can imagine that the set of messages through the proxy actor could get huge and confusing. So, does it make sense to create a proxy for each task to keep things organized? I guess this is more like a best practice question...

Yes, you'll likely want more than one remote proxy.  How many is a matter of taste.  As the designer, it is up to you to strike the balance between the number of messages per proxy and the number of total proxies.  If you stick to a tree hierarchy for your actors, you should be able to define a few subsystems that need to send or receive network traffic.  Those subystems will define some logical cohesion between sets of messages, and you can use that to define your proxies.

0 Kudos
Message 4 of 4
(3,065 Views)