Request with reply to a clonable module considerations

[TiTou]

When sending a request with reply to a clonable module, nothing specific is done if I send that request to all the clones (Module ID = -1), in that case, the caller will receive the reply of the fastest clone only and the others won't be able to reply.

I don't think there is a unique way to deal with this case, to avoid problems when my colleagues use my clonable module, I modified the request VI to throw an error if Module ID = -1, of course it is also documented in the VI's context help and my module documentation but it got me thinking...

Surely the way I handled this is specific to that request in this clonable module.

I think there should be a message (warning?) in the popup when creating a request with reply on a clonable module.

Also I though there could be a few options :

- refuse "-1" as module ID

- if module ID = -1, wait for all clones to reply > the reply argument would then be in an array

I wonder how people handle this, thought?

[drjdpowell · Accepted solution]

---

@TiTou wrote:

- if module ID = -1, wait for all clones to reply > the reply argument would then be in an array

I wonder how people handle this, thought?

---

I don't use the DQMH, but thought I would point out the common terminology of a Request-Reply on multiple modules: "Scatter Gather".   If you implement it, I recommend you include a way to ensure the returned array of the reply argument is sorted in the order of the Module IDs (rather than the time of receipt which is non-deterministic).

[joerg.hampel · Accepted solution]

I think I'd implement a roundtrip rather than a simple request and wait for reply. The website that James linked to (very interesting!) reinforces my feeling that I'd rather wait for all the broadcasts to come in...

[FabiolaDelaCueva · Accepted solution]

I agree with Joerg, I would implement it waiting for all the broadcasts to arrive.

That said, if you feel strongly about your suggestions of warnings or implementing it differently, please add your feature request to:

https://forums.ni.com/t5/Delacor-Toolkits-Documents/DQMH-Feature-Requests/ta-p/3537845

and link to this discussion.

We are working on releasing DQMH 5.0 so this would have to be considered after that release.

Thanks,

Fab

[TiTou]

Thanks for your replies.

My suggestion at this point would simply be to add your suggestion to the DQMH best practises

[drjdpowell]

Note: "Scatter-Gather" can be either Synchronous (wait for all replies) or Asynchronous (have a message containing an array of replies sent to the original Requester).  The later is what is shown in the link (which is why it has an "Aggregator").  

Not quite sure what a "Round Trip" is; I'm guessing you mean have the Request trigger a broadcast to which you have already registered for?  That would have the potential issue of accidentally taking the broadcast generated by a different request (if more than one thing can generate requests).  The advantage of a "reply" is that it is tied to a specific request, and can't get mixed up with replies to other requests.

[TiTou]

---

@drjdpowell wrote:

Not quite sure what a "Round Trip" is; I'm guessing you mean have the Request trigger a broadcast to which you have already registered for?

---

Yes,that's what it is.

---

@drjdpowell wrote:

That would have the potential issue of accidentally taking the broadcast generated by a different request (if more than one thing can generate requests).  The advantage of a "reply" is that it is tied to a specific request, and can't get mixed up with replies to other requests.

---

Good point.

Another possibility is between the moment I get the clone list and they receive the request, some of them might have stopped, in which case the request would timeout.

It would be easy with to send a request to each clone and then wait for the replies but I don't I like the idea of the wait on notifier in a for loop because the timeouts would add-up and potentially make take ages.

For this specific request I have 200 clones so if the timeout is 1 second...

[drjdpowell]

Record the initial time and then calculate the remaining timeout.  Your timeout is the timeout for all replies.   But don't use a notifier as that is lossy; use a temporary queue or user event.

[joerg.hampel]

After reading the comments here and giving it some more thought, I feel that if I wanted/needed dedicated replies from the clones, I probably wouldn't call the request VI with a clone ID of -1. 

- I'd either use a request without reply and a clone ID of -1, and then collect all replies via broadcast

- or address each of them individually with a request with reply VI, but execute those in parallel (call and collect).

@james: Sorry, "Round Trip" is DMQH jargon for a request with reply and a broadcast with the same payload as the reply. In DQMH, the events for requests are created when starting the modules, as are all the broadcast events. Only the notifier that is used for sending the reply value back to the calling VI is generated at runtime when sending the request.