Need Help On Network Endpoint Actor

[TailOfGon]

I am evaluating Network Endpoint Actor to see if it can be used for RT-Host communication. Here is a problem I am seeing.

It is Server/Client model. I created Server Actor and Client Actor, they are independent to each other with some similarity. The attached is the program I implemented. It should be straight-forward.

Goal:

The goal is to allow Server to wait on the next connection whenever a current connection is ended.

Server Actor:

It launches Nested Endpoint Actor with 5000 ms timeout. I set timeout because I want to be able to stop Server Actor when I want to do so. Instead of infinite wait, my strategy is to set the timeout of 5000ms. It throws error 56 when it timeouts. Handle Errors.vi will relaunch the Nested Endpoint Actor if error 56 is detected.

Also, in case the connection between Server and Client is destroyed (for example, by Client stops its Endpoint Actor), I want to relaunch Server's Endpoint Actor so it can wait on the next client. I have a problem with this. I have a time-delayed message that checks whether Server's Enqueuer is null. If null, relaunch the Endpoint Actor. But Equals Not A Refnum VI shows always False even after Client stops the Endpoint Actor. How can I know it's time to relaunch the Endpoint Actor?

Client Actor:

It launches Nested Endpoint Actor when a user requests to do so. It disconnects the connection by calling Normal Stop on the actor.

To run the VIs:

1. Run the Server Launcher first
   
2. Run the Client X Launcher next
3. Click on the 'Connect' button. Both LEDs will turn on
4. Now click on the 'Disconnect' button. Client's LED turns off but Server's LED doesn't.

New file was added by: TailOfGon

[CaseyLamers1]

I am looking at your example and I think it is missing a parent class

Without running the code, I can say a few things.

When you execute "Launch Network Endpoint Actor" in the Server Actor you put the enqueuer in the private data, and from there on it is not changed. In other words, it is a Valid Refnum.

When you run the "Equals Not A Refnum" it is False unless you write a default Enqueuer constant for the "Nested Endpoint Enqueuer". The default constant for the enqueuer is the only way to get "Equals Not A Refnum" to be True.

So, in the Handle Error for error code 56 you should put a default Enqueuer constant on the wire and then send the message to launch the endpoint.

Casey

[justACS]

Here is the simplest way to have your server detect that its endpoint has terminated and restart it.

When the server endpoint terminates (due to a broken connection, or from timing out while waiting), it will send its caller a Last Ack message.  Use this fact.

1.  In the caller, create an override of Handle Last Ack Core.vi.

2.  In Handle Last Ack Core, use the Read Actor method of Last Ack to get the nested endpoint actor.

3.  Relaunch the endpoint using Launch Nested Actor.vi

4.  Save the endpoint enqueuer for later use.

Here is a block diagram illustrating the concept:

Checking to see if the enqueuer won't work, for the reasone Casey outlined (i.e. a dead enqueuer is still an enqueuer).  And checking runs counter to the philosophy of the framework, anyway.  Let the endpoint tell you when its done, and respond.

[TailOfGon]

Casey:

Thanks for pointing that out about the linking. The new attachment file includes the fix.

niACS:

Thank you for letting me know about correct way to handle the timeout and disconnect. I also thought checking the connection is against the philosophy of framework, but could not think of any other way. I have updated the file and uploaded into the first thread. At least it is working well on my end.

[justACS]

I won't go so far as to say it is the correct way to solve the problem.  It is the cleanest ands simplest, which makes it the best choice in many (possibly most) cases.

I went back and added this information to the main Network Actor page.

[TailOfGon]

niACS,

Again, thank you for your support. I feel much more comfortable using this framework now.

[crandiba]

Hi justACS

First I have to say awesome job! Ever since hearing about them I wanted to give NEA a go and I should say its really great!

I wasn't sure where to post this but I wanted to share my little experience on getting it on a Host + cRIO application, in case its useful.
I ran into the error 1527, unflatten failed since the class was not loaded into memory. It comes from a message class (contained inside the RT actor's .lib) that only actually gets sent from the Host side. I took it as the compilation stripping it away somehow but it was a bit more than that; If I just drop it into the diagram or have some code dependency it solves the issue, but what I wanted to share was more the fact that the Report Error on the Listener's Receive message is just a dead end; you explain it well in the comments, but I would argue there is a case to already provide an (already shipped) override here that will send it to the caller or otherwise pass it/handle it.

Thanks again for the awesome job, it really makes a difference for everyone!

Best

Cris

[Jpurdy]

---

@crandiba wrote:

Hi justACS

First I have to say awesome job! Ever since hearing about them I wanted to give NEA a go and I should say its really great!

I wasn't sure where to post this but I wanted to share my little experience on getting it on a Host + cRIO application, in case its useful.
I ran into the error 1527, unflatten failed since the class was not loaded into memory. It comes from a message class (contained inside the RT actor's .lib) that only actually gets sent from the Host side. I took it as the compilation stripping it away somehow but it was a bit more than that; If I just drop it into the diagram or have some code dependency it solves the issue, but what I wanted to share was more the fact that the Report Error on the Listener's Receive message is just a dead end; you explain it well in the comments, but I would argue there is a case to already provide an (already shipped) override here that will send it to the caller or otherwise pass it/handle it.

Thanks again for the awesome job, it really makes a difference for everyone!

Best

Cris

---

I am having the same issue.  What class did you put into memory to fix the problem?

Thank,

Jim

[crandiba]

Hi Jim,

Given 2 actors: Actor 1(host; sender of the message) and Actor 2 (target; receiver of the message), Actor 2 need to have the Message class that you are sending loaded into memory, otherwise it will fail to 'unflatten' it. The same is true for messages set from Actor 2 to Actor 1. 

Lemme know if it made sense,

Cris

[Jpurdy]

Yes, It makes sense.  As you describe, there is a message being sent on connection that produces the 1527 error and triggers a Last-Ack restart.   Is the message that is required to be loaded from a LV library or ???.

I have placed instances of all my message classes (that are to be used) on my actor core of the VI using the NEA.  Is that the correct placement?

Thanks,

Jim