Architecture Validation

[Taggart]

In some ways it is circular. If you send a roundtrip message and you are registered for the broadcast then at some point you get a message back saying that it finished. 

[drjdpowell]

---

@Taggart wrote:

In some ways it is circular. If you send a roundtrip message and you are registered for the broadcast then at some point you get a message back saying that it finished. 

---

That sounds like an attempt to get a Reply back asynchronously.  It's a potentially dangerous one if there are multiple requesters.  For example, if I request "what is 2+2", and someone else (just before me) asks "what is 2+3", I might come to the conclusion that 2+2=5.

[Taggart]

Fair point.

[joerg.hampel]

---

@drjdpowell wrote:

---

@Taggart wrote:

In some ways it is circular. If you send a roundtrip message and you are registered for the broadcast then at some point you get a message back saying that it finished. 

---

That sounds like an attempt to get a Reply back asynchronously.  It's a potentially dangerous one if there are multiple requesters.  For example, if I request "what is 2+2", and someone else (just before me) asks "what is 2+3", I might come to the conclusion that 2+2=5.

---

...and that reminds me of James' talk about futures/promises...

[Darren]

---

@drjdpowell wrote:

---

---

That sounds like an attempt to get a Reply back asynchronously.  It's a potentially dangerous one if there are multiple requesters.  For example, if I request "what is 2+2", and someone else (just before me) asks "what is 2+3", I might come to the conclusion that 2+2=5.

---

If you request 2+2, then you'll use the reply payload output of the Request VI to see what the answer is. So will whoever (just before you) asked what 2+3 was. You'll both get the right answer with this approach. That also means that neither of you is registered for the broadcast of the round trip. In Tom's LabVIEW Adventure video that discusses DQMH round trips, he describes a good round trip use case... in his example, there's a request to update firmware on a hardware module. It's a round trip, so whoever requested to update the firmware will receive the response that it is updated, but there's also a broadcast telling any other interested modules that the firmware is updated, in case they need that info for whatever reason.

[Enrique.Noe]

This is exactly how I understand the round trip, a request and wait for reply for the calling code and an extra broadcast with the same reply to all the possible listeners.

Enrique.

[drjdpowell]

That just circles me back to my point that "round trip" is a nonintuitive name for a "wait for reply and notify others".  

[drjdpowell]

---

@Darren wrote:

---

@drjdpowell wrote:

---

---

That sounds like an attempt to get a Reply back asynchronously.  It's a potentially dangerous one if there are multiple requesters.  For example, if I request "what is 2+2", and someone else (just before me) asks "what is 2+3", I might come to the conclusion that 2+2=5.

---

If you request 2+2, then you'll use the reply payload output of the Request VI to see what the answer is. So will whoever (just before you) asked what 2+3 was. .

---

That's a synchronous (or blocking) Request-Reply.  A very good messaging pattern, but there is also asynchronous Request-Reply, where one isn't blocked waiting on the reply.  Taggert's suggested use sounds like an attempt to get a reply in a non-blocking manner.