4 ms·

> we're assuming perfect communication between the process/driver/hardware receiving the packets and doing the duplicate detection and the process which wants t

by lisper 2y ago

> we're assuming perfect communication between the process/driver/hardware receiving the packets and doing the duplicate detection and the process which wants to receive the message exactly once My claim is not that you can provide exactly-once delivery unconditionally. My claim is that if you can provide at-least-once delivery then you can turn that into exactly-once delivery. The word "delivery" is not rigorously defined, but IMO any reasonable definition necessarily entails a certain level of reliability at the receiving node.

Ayyyyyron 2y ago
I agree with your claim, a recipient can cope with at-least-once delivery by being idempotent. You're right. The meaningful distinction is that something on the recipient needs to be idempotent because the message might get received twice. The application can be oblivious to this, so long as you assume that channel to be perfect. People on the Internet won't like you calling it 'exactly once delivery' because it's not exactly once - it's an idempotent at-least-once. Which is great! But the statement of the at-least/at-most problem is making a decision to re-try. There's no middle ground, I either have to retry or not. People won't like a claim that 'exactly once' delivery is possible, because it isn't, it's just moving the at-least-once-ness to somewhere else.
- lisper 2y ago
  > People on the Internet won't like you calling it 'exactly once delivery' because it's not exactly once That depends entirely on what you mean by "it". Messages can get lost. So if you want guaranteed delivery, you sometimes have to re-transmit the same message, and so you might end up with the same message being delivered more than once. But it is trivial to put an abstraction layer on top of that to discard the duplicates and make it appear to the application as if every message is received exactly once. The whole thing is a tempest in a teapot.

by lisper 2y ago

Ayyyyyron 2y ago

I agree with your claim, a recipient can cope with at-least-once delivery by being idempotent. You're right. The meaningful distinction is that something on the recipient needs to be idempotent because the message might get received twice. The application can be oblivious to this, so long as you assume that channel to be perfect. People on the Internet won't like you calling it 'exactly once delivery' because it's not exactly once - it's an idempotent at-least-once. Which is great! But the statement of the at-least/at-most problem is making a decision to re-try. There's no middle ground, I either have to retry or not. People won't like a claim that 'exactly once' delivery is possible, because it isn't, it's just moving the at-least-once-ness to somewhere else.

lisper 2y ago
> People on the Internet won't like you calling it 'exactly once delivery' because it's not exactly once That depends entirely on what you mean by "it". Messages can get lost. So if you want guaranteed delivery, you sometimes have to re-transmit the same message, and so you might end up with the same message being delivered more than once. But it is trivial to put an abstraction layer on top of that to discard the duplicates and make it appear to the application as if every message is received exactly once. The whole thing is a tempest in a teapot.