"Guarantee" processing order of received messages

[deldrid1]

Bullwinkle is tremendously helpful for making agent/device comms more robust, but I've run into a corner case today with retries.

The basic issue is that I am not defending well against receiving messages out of order, which will happen if you have a dropped packet and then retry and are sending messages fairly regularly (~once/second seems to do it for me). My code was architected to be robust against dropped messages, but receiving a message after I've already processed a newer one is something that I don't handle very well...

I need to dig into the code a bit, but I'm guessing that an ever incrementing sequence number could be added to each message. If you notice on the partner that a message was skipped, you could wait for some time (half the timeout?) for the retry to be successful and then have those messages handled in the correct order for the .on() code. There might also be some opportunity for prioritizing sending retries vs. regular .send messages on the side where messages originate.

[ppetrosh]

Hi Austin, I completely agree with what you propose. And I think it makes a lot of sense if our primary use case is based on the proper message order. While if it in fact requires messages to be sent as soon as possible (some real-time use case), then delaying a delivery for the sake of a message that missed the train might be harmful. I can easily imagine such a case. So we can probably provide a sample handling the issue for users at the app level and explicitly document this behavior in the dev center. If we see a further demand from customers, we can consider including this option to choose a message delivery strategy in the library. Does it make sense?

[deldrid1]

Yes makes perfect sense and our app actually has both use cases embedded (control commands should be delivered in "real time" versus some data collection which should ideally be ordered). I'm good with either approach (and if this ticket didn't see some action was planning on implementing message ordering by extending the Bullwinkle class or one of our own classes and overriding a few methods to include a message sequence number and handle message ordering at the "app" level).

However, I might challenge the notion that the primary use case for Bullwinkle is real-time communication? This feels a bit like a TCP vs. UDP discussion to me - if your real-time requirement trumps message ordering, then you likely don't care about dropped packets anyway and in that case why are you using a helper library like Bullwinkle (which implements ACKs, retries, etc.) instead of just using the best effort device/agent.send methods to stream the data as quickly as possible?

[ppetrosh]

I tend to agree with you that if you want messages to be delivered as soon as possible you might also want to preserve the order. This makes sense to me.

We'll monitor the library use case and if this turns to be a frequent use case, we'll consider adding this optional feature into the library. This would become even easier when we have a code preprocessor that would allow us to add optional features without impacting the footprint of apps the don't really use them.

[deldrid1]

I thought versioned libraries were just an excuse for allowing code bloat as the numbers get bigger :)

With impOS 34, growing Bullwinkle slightly to do message sequences shouldn't be a big deal? I've not looked into the implementation too much but I would guess that most messages are received in bursts anyways, so I'm guessing this could be done without too much of a performance or code size increase impact.

[ppetrosh]

Makes sense to me. My suggestion is to extend the Bullwinkle for now with the required functionality. Meanwhile we'll keep it watching to make sure this is a generic feature demanded by other developers which needs to be added to the core library. If we end up adding this feature, I'd probably make it configurable. Please let me know if you need any help with working this around in the application code.

[ppetrosh]

I believe MessageManager/ReplayMessenger are designed to address this requirement. So I'd probably close this issue.