Hacker News Reader

Comment by rubiquity | Hacker News Reader

> Guaranteed delivery of a message to exactly one recipient within a messages visibility timeout.

I'll just leave this here for you: http://bravenewgeek.com/you-cannot-have-exactly-once-deliver...

Welcome to message queues. Where the network is both your best friend and enemy.

MQTT uses a 2PC-like mechanism for exactly-once delivery [1]. The sender sends and the receiver acks as usual. But the message is only delivered once the sender then sends a release message, which the receiver acks. End result: sender can assume receiver distributed the message only once.

[1] http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-o...

That's not exactly once. There are several failure modes that can cause duplication. You can detect duplication but not prevent it.

It depends on how you define the scope of the delivery, which is mentioned in the article. MQTT's exactly-once ensures that the receiver delivers the message to the end application exactly once, even if there had been duplicated messages between the sender and the receiver.

Sure. But that is true of all messaging systems. When people are discussing whether something is at-most-once or at-least-once they are talking about independent of the protocol.

The reason that is important is because it has large ramifications for other parts of the delivery promise (such as order guarantees) or the implementation of the protocol (such as how chatty MQTT is).

It is relatively trivial to implement a system with exactly once delivery if you allow for client filtering and don't have performance or delivery time constraints.

It's not exactly "once". It's exactly "one" within a defined period of time. So in that articles context it would be the "at-least-once" variant.

If the recipient fails to process the message for some reason it will reappear after the visibility timeout.

I don't think you can provide exactly once even with that constraint. What if the defined period of time was 100 years?

Then you need a very big buffer.

Reply on news.ycombinator.com