How to implement a parent message class to send common data between actors

[manig]

Actor Tree: My application has multiple actors launched by a root actor. A few of the actors(Interface Actors) talk  to hardware to collect data and send it back(broadcast) to all other actors(display actors) when it receives a request.

Scenario: Two display actors send the same request message within a few milliseconds to an interface actor and the interface actor broadcasts the response. Display actors  will receive the response but it cannot differentiate if the response is for the request it sent. So it needs a mechanism to differentiate.

One way to do it would be to send back the requested inputs along with the response so the display actor can check the response contents and consume it.

One other way is for the request message to have a unique ID as input which will be sent by the requester and the Interface actor can send the response along with the received ID. So each response will have unique ID to differentiate.

I can add an ID input to all messages but thinking if there is an other way such that all messages will have unique ID by default through inheritance from parent message class. My understanding is that the parent message contents cannot be passed on to Actor in a straight forward way and we may need to modify the message script or Do.vi.

Please let me know if there is better way to do this.

Thank you,

Mani.

[IlluminatedG]

Why is the broadcast indistinguishable from a request response? If its because its the same data type then why is a different message needed to request the data if its already sent? There's some details missing from the picture here but it seems to me like there's already some funkiness around the message reuse and the purpose of the messages needs to be revisited. In AF they're "messages" but its really to be viewed as a command request since it's the command pattern and invokes a specific VI on an actor to send a request with parameters (such as update your knowledge of the system state with this new data, please!)

As far as I see you would need that ID field (empty for broadcast? populated with request ID? still seems odd to have this kind of sharing to me) and I wouldn't bother with trying to abstract it. It's literally just adding that input to a VI that you create the message from. It's not like you make the message and then make the VIs and need to share behavior. The AF tooling makes sharing data between messages not really a thing.

[CaseyM]

I think I understood the scenario/question a little differently from @IlluminatedG, but I still have questions.

---

@manig wrote:

Scenario: Two display actors send the same request message within a few milliseconds to an interface actor and the interface actor broadcasts the response. Display actors  will receive the response but it cannot differentiate if the response is for the request it sent. So it needs a mechanism to differentiate.

You're using "broadcast" and "response" to refer to the same message from the hardware interface actor, correct? What about the response makes it necessary for the display actor know to which request it was a response to?

I can't be sure without more details, but it sorta sounds like the messages between the display and the interface actors have some implicit dependencies on one another that you might be able to get rid of. The fact that you want to do this for multiple sets of messages only increases my suspicion.

[drjdpowell]

Take a moment to think how email works. If I were to receive two requests by email, I would reply to those emails, and the requestors would not need to figure out which reply is meant for them.  They would not be trying to decipher a stream of broadcasts.

[manig]

---

You're using "broadcast" and "response" to refer to the same message from the hardware interface actor, correct?

 That is right. The response message is broadcast to all actors.

---

What about the response makes it necessary for the display actor know to which request it was a response to?

---

Please let me know if the below example explains the scenario better,

Display Actor 1 & 2 (DA1, DA2): Actors display images in UI and also do different processing and have different steps to execute after receiving the image.

Camera Interface Actor (CA) :  Configure camera parameters and gets a snapshot from a camera

DA1 sends a message to CA to get a snapshot with ROI of 100 * 100. DA2 sends a message to CA to get a snapshot with ROI of 200 * 200 (note, both are same message with different ROI inputs). CA sends back the response to both DA1 & DA2. We cannot launch multiple CA actor as we can only open one reference to camera at a time. So Root actor launches CA, DA1 & DA2.

Now the DA1 & DA2 need to differentiate the response and consume only what is intended for it.

[manig]

Powel, That is exactly what I was thinking about. How to implement that email sort of solution in the actor framework. I think I read one of your posts mentioning this example and got inspired by it. But I don't recollect a solution from that post.

[manig]

---

@IlluminatedG wrote:

Why is the broadcast indistinguishable from a request response? If its because its the same data type then why is a different message needed to request the data if its already sent? There's some details missing from the picture here but it seems to me like there's already some funkiness around the message reuse and the purpose of the messages needs to be revisited. In AF they're "messages" but its really to be viewed as a command request since it's the command pattern and invokes a specific VI on an actor to send a request with parameters (such as update your knowledge of the system state with this new data, please!)

---

I apologize if the terminologies are confusing in my post. I meant all the response messages are broadcast to all actors.

As far as I see you would need that ID field (empty for broadcast? populated with request ID? still seems odd to have this kind of sharing to me) and I wouldn't bother with trying to abstract it. It's literally just adding that input to a VI that you create the message from. It's not like you make the message and then make the VIs and need to share behavior. The AF tooling makes sharing data between messages not really a thing.

---

Yes, I can add the ID to each message as input but was wondering if this can be abstracted as this is becoming a common pattern.

[CaseyM]

---

@manig wrote:
Display Actor 1 & 2 (DA1, DA2): Actors display images in UI and also do different processing and have different steps to execute after receiving the image.

Camera Interface Actor (CA) :  Configure camera parameters and gets a snapshot from a camera

DA1 sends a message to CA to get a snapshot with ROI of 100 * 100. DA2 sends a message to CA to get a snapshot with ROI of 200 * 200 (note, both are same message with different ROI inputs). CA sends back the response to both DA1 & DA2. We cannot launch multiple CA actor as we can only open one reference to camera at a time. So Root actor launches CA, DA1 & DA2.

Now the DA1 & DA2 need to differentiate the response and consume only what is intended for it.

---

And CA is always capturing the same image only with different ROIs? In that case, I'd have the CA send the full image in its message and let DA1 and DA2 apply their own specific ROI to the image. It would also be up to them to determine if a message that comes from CA is relevant to them - at some times, it may be and at others it may not.

Would that work?

[drjdpowell]

---

@manig wrote:

Powel, That is exactly what I was thinking about. How to implement that email sort of solution in the actor framework. I think I read one of your posts mentioning this example and got inspired by it. But I don't recollect a solution from that post.

---

With email the address to reply to is contained in the message.  One doesn't broadcast the reply to everyone in your address book and let them figure out which messages to ignore.  With AF this would involve putting the requesting Actor's Enqueuer in the Request message.

[manig]

Thanks, @CaseyM. If there are operations that can only be performed by the Camera Actor, like setting exposure time or ROI (a camera parameter instead of post-processing), we will not be able to delegate them to the display actor.