Multi-Client Handling using LNA

[TailOfGon]

Hi, I am working with my sbRIO to accomplish the following.

Requirements:

• sbRIO will be Fully Actor Framework based RT system
• sbRIO will communicate with Fully Actor Framework based host application.
• sbRIO can be connected from multiple hosts up to 4 simultaneously (1, 2, 3 or 4 connections at once)
• Connection between host and RT will be done using LNA.
  
• sbRIO will have 4 control loops, each of which will be configured and controlled by a dedicated host. A host application can only configure and operate on a single control loop.

Strategy I have in mind:

• The RT controller launches a LNA based server (let's call it LNA Distributor Server) that a host first connects to and then eventually disconnected once a new LNA connection is launched.
  
• Host launches another LNA based client (let's call it LNA Distributor Client) that is responsible for connecting to the LNA Distributor Server
  
• LNA Distributor Client (host) connects to the LNA Distributor Server (RT).
  
• LNA Distributor Server generates a UID, say "XYZ", then launches a new LNA instance named "XYZ" on sbRIO, and pass the name (string) to the host using LNA Distributor line.
• Once host receives the UID, it stops the LNA Distributor client, and then generates a new LNA and uses the UID to connect to the LNA named "XYZ".
• Once the connection is successful, it can start sending messages to RT controller.
• Upon connection, the host requests a permission to one of the control loops (0-3) that a user chooses. Once the permission accepted, host can start sending messages to change or operate on the permitted control loop. The permitted loop will be marked such that nobody else can claim later.
  

Problem I have:

• host will be sending messages to the RT controller to run requested methods. But when the RT controller method gets executed, the method cannot know from which connection this message was sent. Say, if a connection is only permitted to work with control loop 0, when the method is executed to run on loop 1, I want to either ignore the request or throw an error. But the AF doesn't really tell me from which pipe the request was given.

My quick solution will be that when a permission is given to the host, RT controller gives the unique random key string like "984rjlka45ug" to the host LNA. The key will be stored in a look up table along with the permitted action. All the loop specific RT method will have a 'key' terminal. When a host sends a message to the RT, it has to include the key in the message. The key will be looked up within the method for validation.

All the AF enthusiasts and masters, do you think this solution is a good idea to begin with or there is a better solution that you guys do already? This is my first ever multi-session architecture. Any advise is appreciated.

[justACS]

First off, take a look at Network Endpoints:  Network Endpoint Actors

These are single use connections, and I think they will work better when you want a central service serving up connections.  They also support Network Streams and TCP/IP.

That said, if you want each of your four RT actors to be accessed directly by a single host, why not have a dedicated connection per RT actor?  You don't need to worry about creating a new connection on the fly.  If you don't want the connections to be live all the time, you can have your central controller ask the four nested actors to create connections when needed.

As for controlling which messages the RT actors can receive, write remote proxy actors for them that manage the network connection and define a fixed set of messages that can move between the host and target actors.  See the example here:  Actor Framework on CompactRIO (and Other RT Targets).

[TailOfGon]

Thank you niACS

First off, take a look at Network Endpoints:  Network Endpoint Actors

I was wondering about this. Will take a look.

That said, if you want each of your four RT actors to be accessed directly by a single host, why not have a dedicated connection per RT actor?  You don't need to worry about creating a new connection on the fly.  If you don't want the connections to be live all the time, you can have your central controller ask the four nested actors to create connections when needed.

Does it mean to create multiple rt controller actors each serving a single connection and a control loop? That solves my problem but I prefer having a central controller that takes all the messages from all users. But having a central controller means I cannot know the sender's information.

The more I think about it, I think it is conceptually wrong to try to identify the sender of a message.

[TailOfGon]

niACS, I'm looking at Network Endpoint Actors. I see in the example that there is a TCP/IP implementation and a Network Stream implementation. From a discussion thread somewhere, I saw people talking about TCP/IP being a better approach than Network Stream especially when dealing with multiple simultaneous connections.

In my case I need 1 connection for a user to access to at first and up to 4 additional connections. 5 connections in total. In this case, do you recommend to use TCP/IP flavor of Network Endpoint Actor? What will be the benefit of using Network Stream flavor of the actor in this case?

[justACS]

TailOfGon wrote:

Does it mean to create multiple rt controller actors each serving a single connection and a control loop? That solves my problem but I prefer having a central controller that takes all the messages from all users.

Why?  It's a bottleneck.  All your traffic routes through a single actor, which then has to farm messages out to its nested actors.  That actor needs to be able to handle all of the messages it nested actors can receive, which means 2x the number of method VIs and 2x the message classes.  Your central controller is going to get very big, very quickly.

On the other hand, you can write your central controller to accept four messages only - one per control loop.  Each message causes the controller to send a message to one of the four control loops to open its specific comm channel.  Then the controller can send a message to the host with connection information.  The host can disconnect and then connect to its specific RT loop.

(Though this begs a question:  why do you need a gatekeeper?  What purpose does it serve?)

But having a central controller means I cannot know the sender's information.

The more I think about it, I think it is conceptually wrong to try to identify the sender of a message.

If the message comes from another actor, you basically can't, because the calling actor can share its nested actor's enqueuer with other actors.  A caller can't even tell if a message is coming from its own nested actors or helper loops.  It just gets a message.

The only thing you can control is the messages an actor can receive.

[justACS]

TailOfGon wrote:

In my case I need 1 connection for a user to access to at first and up to 4 additional connections. 5 connections in total. In this case, do you recommend to use TCP/IP flavor of Network Endpoint Actor? What will be the benefit of using Network Stream flavor of the actor in this case?

Network streams are supposed to have some additional guarantees around making sure data is delivered.  This is mostly to protect the integrity of, well, streaming data.  It seems like those guarantees would be useful in a remote messaging architecture.  I don't know if that has proven to be the case, however, and network streams are restricted to Windows and our RT targets.  So I don't actually have a recommendation for you.

The good news is that you can start with either one, and easily swap to the other if it doesn't work out.  The ability to do that was a large motivator in creating the network endpoints, and part of why I'm suggesting people look at them instead of the Linked Network Actor.