Comment by lisper

Comment by lisper 10 months ago

6 replies

> A 4 year old piece laying out the exact difference...

"Exactly-once delivery guarantee is the guarantee that a message can be delivered to a recipient once, and only once."

That seems circular to me.

Also, the author's proof is flawed. The 2GP requires more than exactly-once delivery, it requires common knowledge. It is not enough for the first general to know that the message will be received, it is required that the first general knows that the message has been received, and that the second general knows that the first general knows this, and that the first general knows that the second general knows... and so on.

mlyle 10 months ago

The piece makes a very simple distinction.

Delivery is the property of a message showing up at a receiver, irrespective of the receiver making state changes.

Processing is making state changes.

You can't dedupe messages without some kind of state change. Your guards, writing down that a given message has been here before, have been delivered the message. An endpoint on a lossy medium has to cope with either (0 or 1) or (1 or many) messages.

Now, can the guards deliver it to you at most once? Well, if there's no lossy medium between, sure. But we already know that we can deliver exactly once when the medium is perfectly reliable. The guards have "processed" the message for this purpose, and the fact that they can deliver it to you over a perfectly reliable channel is moot.

The distinction is between the characteristics of the channel (delivery) versus what the receiver must do to achieve appropriate processing properties.

These might come from some combination of intrinsic idempotency, timers, persisting past messages to disks, establishing a message ordering, etc, etc, etc. These are the mechanisms that you need to cope with "one or many" delivery, and they all shape the state model of your system with respect to messages.

  • lisper 10 months ago

    > The guards have "processed" the message for this purpose, and the fact that they can deliver it to you over a perfectly reliable channel is moot.

    No, it isn't, because the situation inside the fort is different than the situation outside. The odds of a courier being intercepted inside the fort are effectively zero. If your computational model includes a non-zero probability of failure "inside the fort" then you are no longer in the realm of distributed systems, but are now talking about fault-tolerant computing, which is a whole nuther kettle o worms.

    • pyrolistical 10 months ago

      No, one of the key ideas in distributed systems is the network is unreliable. It’s not bad actors “inside the fort” it’s just that messages get lost sometimes.

      Internal switches can fail. There are countless reasons why packets will get lost

      • lisper 10 months ago

        "Inside the fort" is a metaphor for a single server, not anything involving a network.

    • mlyle 10 months ago

      No. An element of a distributed system that wants to debit from bank accounts must acknowledge the receipt of a message after making its effects durable. That system may fail between the change being durable and the acknowledgment making it back to the original sender.

      That element must tolerate that debit being delivered multiple times. And we can't even solve that problem by a higher-order system providing "reliable delivery" on that element, unless that thing persists atomically with the application performing the transaction (or the application itself tolerates multiple delivery).

      • lisper 10 months ago

        > An element of a distributed system that wants to debit from bank accounts must acknowledge the receipt of a message after making its effects durable.

        I do not and never have disputed that. But I fail to see what that has to do with the matter at hand, namely, whether or not exactly-once delivery is possible.