More examples or tutorials for Messengers with Ack?

[Blokk]

Thanks for the clarification of this behaviour! I play more with Messengers as I have time, and if I have more questions I will get back to this post!

Best Regards,

[wired-dan]

---

What was happening was on the first call the ack id was not found, causing the caller (Endpoint.vi) to wait.  But the returned id was 0, so on the next call it attempted to wait for ack id 0, which is a no-op that returns immediately.

---

Are you saying that the bug causes the wait for ack to return immediately? I found that it will wait for at least one non-zero ack id to be written.

Taking the same example I had, try wiring a zero constant instead of a non-zero. The channel reader will keep waiting...

[jkodosky]

The Write Endpoint calls Endpoint.vi which has a loop.  During WriteSync it calls the channel implementation VI with the correct ack id, but the return from that call indicates Endpoint.vi should wait because the ack has not been seen yet.  Endpoint.vi waits for an occurrence (set by the ReadEndpoint when it is ack-ing a non-zero id as part of it's Read call; or set by WriteAck endpoint) and then does another iteration of it's loop calling the channel implementation VI again.  However, this time the ack id is 0 because it was lost during the previous call, and so the channel implementation VI returns "done" and the Endpoint.vi finishes (without ever having gotten an ack for the id it was called with).

It's hard to explain in words, but if you drill down from the Write endpoint you can see the various layers and what's going on.  A note of caution: inside these layers there is trickery being played with the Channel wire.  Just ignore the trickery, and don't mess with it!

[Ben]

---

@jkodosky wrote:

...

.  A note of caution: inside these layers there is trickery being played with the Channel wire.  Just ignore the trickery, and don't mess with it!

---

Is there a resemblance there or is that just my brain playing games with me?

Ben

[AaronTeitlebaum]

---

@AristosQueue (NI) wrote:

Every message sent gets a unique ID in sequence order. At the Read endpoint, one of the terminals gives you the ID of that message. You then use Write Ack to acknowledge that particular message.

The Write endpoint has an ID output so that elsewhere you can use Read Ack to wait for that particular ID to be acknowledged. The Write endpoint has a Wait For Ack Boolean input that, if true, will cause the Write to hang until the message being sent is acknowledged (i.e., it does the Read Ack internally).

---

I apologize for bringing up this four-year-old thread, but I've been puzzling over how to use acknowledgements with Messenger channels without much success, and this comment above seems relevant. It says that the message Read endpoint is supposed to output the ID of the message that it reads, so that the message can be acknowledged either by inputting the ID to the Read endpoint the next time it's called, or by using the "Write Ack" endpoint. However, at least in LV 2020 SP1 on my PC, the Read endpoint does not output the ID of the message it reads, there's no terminal for it, and seemingly no way to find out the ID other than transmitting it separately through another channel. Did this change at some point in the last four years, or am I missing another way to determine the ID of a read message?

[jkodosky]

The Messenger channel originally only worked for message data which was a class that inherited from vi.lib/Channel Support/Channel Message.lvclass.  That class contains an ID field which enabled the ack mechanism to work.  The channel was then extended to support other data types.  It did this by automatically creating a new class inheriting from Channel Message and having one member data item, namely, the data connected to the Write endpoint.  This added undesirable overhead and complexity to the channel, so it was decided to simplify by supporting the ID mechanism only if a class data type was used explicitly-- the channel would no longer create an otherwise inaccessible one behind the scenes.

The current Messenger channel improves on that situation slightly: data of any class (not just those inheriting from Channel Message) can support the ID mechanism as long as the class supplies a Write ID method and a Read ID method.  The Write ID method is called from inside the Write endpoint call.  You have to call the Read ID method explicitly on the data returned by the Read endpoint.  It would be more convenient if it were called inside the Read endpoint and the ID were made available on the endpoint itself.

It is highly recommended that a class be used for Messenger channel data, not only to enable usage of the ID ack mechanism but also to enable usage of the merge mechanism, if desired (check out Examples/Channels/Messenger for more info).  This all should be explained more clearly in the Messenger channel documentation.

Bottom line: The ID mechanism works only for class data.  Creating a limited and inaccessible class behind the scenes was a bad idea.  The Read endpoint should be fixed to have an output ID terminal.  The documentation should explain the situation more clearly.  And yes, there should be more examples or tutorials for Messenger channels with Ack.  

[sth]

I see the reasoning behind this.  It would be very helpful if such a thing was in the examples.  Is it?  I can't check right now since my 2020 installation seems to be broken and the ability to download the Mac/linux installers from NI was broken and I haven't checked today.  The linux ones were fixed and they were working on the Mac from my service request.