ni.com checkout is currently experiencing issues.
Support teams are actively working on the resolution.
ni.com checkout is currently experiencing issues.
Support teams are actively working on the resolution.
11-16-2015 05:06 PM
Hi, I am working with my sbRIO to accomplish the following.
Requirements:
Strategy I have in mind:
Problem I have:
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.
11-16-2015 05:27 PM
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).
11-16-2015 06:27 PM
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.
11-17-2015 10:54 AM
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?
11-17-2015 11:09 AM
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.
11-17-2015 11:15 AM
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.