24 ms·

>a simple matter of keeping track of all the delivered messages and removing duplicates Ron, if you have received duplicate messages then by definition you hav

>a simple matter of keeping track of all the delivered messages and removing duplicates Ron, if you have received duplicate messages then by definition you have been delivered that message more than once. I don't have a PhD in computer science so maybe you can explain how this constitutes "exactly once".

lisper 2y ago
> if you have received duplicate messages then by definition you have been delivered that message more than once Yes. So? If you don't include a mechanism for ensuring exactly-once delivery then you will not be guaranteed exactly-once delivery. But if you do, you will. It doesn't actually require a Ph.D.
- stackghost 2y ago
  >> if you have received duplicate messages then by definition you have been delivered that message more than once >Yes. Okay, I'm glad we agree that delivering something multiple times and discarding the duplicates is not exactly-once delivery.
  - lisper 2y ago
    As you have described it, you are right, it's not. But presumably the thing discarding the duplicates then does something with the non-duplicates, like deliver then to something else. That is exactly-once delivery.
    - stackghost 2y ago
      You wrote in the post: >This post was intended to be about human communication more than distributed systems or network protocols But resorting to technical minutiae as you have done doesn't seem germane to "human communication". Honestly, seeing such mental gymnastics just to avoid losing face on an internet argument is really disappointing.
      - lisper 2y ago
        What you call "technical minutiae" I call "the meanings of words", which is very germane to the matter of human communication.
    - mlyle 2y ago
      To discard the duplicates, you need to update your state based on the first message and consult that state for all subsequent messages. Someone must be delivered those messages for this to happen. If you say that someone can then pass you messages exactly once over a perfectly reliable channel, well.. sure. But the system still has to deal with duplicate delivery and update its state based on that. (And potentially must durably persist this state. And, then, if your application doesn't have exactly the same persistence/transactional boundaries as what's doing the deduping, you have problems...).
      - lisper 2y ago
        > To discard the duplicates, you need to update your state based on the first message and consult that state for all subsequent messages. Someone must be delivered those messages for this to happen. Yes, that's right. > If you say that someone can then pass you messages exactly once over a perfectly reliable channel, well.. sure. So you concede that you were wrong? > But the system still has to deal with duplicate delivery and update its state based on that. Well, part of the system does. But that part can be hidden behind an abstraction layer so that "you" can have exactly-once delivery doe some value of "you". > (And potentially must durably persist this state. And, then, if your application doesn't have exactly the same persistence/transactional boundaries as what's doing the deduping, you have problems...). Sure, but as I pointed out to you in the other thread in which we are engaged, that is irrelevant to the question of whether or not exactly-once delivery is possible.
        mlyle 2y ago
        No, considering something at the end of a fault-free channel as the element of the distributed system being delivered to is silly. > we are engaged We are no longer engaged, because I've given up on talking to you. You can use "delivered" however you like by yourself, as you're eliminating everyone else's desire to listen to you. I think it's ridiculous that you're back to continue to poke this a day later. Find a hobby. Or read a textbook. I suggest Steen and Tanenbaum, which explains exactly-once semantics in distributed systems in a careful and thorough way (though this particular book doesn't say "delivery", unlike many others.

lisper 2y ago

> if you have received duplicate messages then by definition you have been delivered that message more than once Yes. So? If you don't include a mechanism for ensuring exactly-once delivery then you will not be guaranteed exactly-once delivery. But if you do, you will. It doesn't actually require a Ph.D.

stackghost 2y ago
>> if you have received duplicate messages then by definition you have been delivered that message more than once >Yes. Okay, I'm glad we agree that delivering something multiple times and discarding the duplicates is not exactly-once delivery.
- lisper 2y ago
  As you have described it, you are right, it's not. But presumably the thing discarding the duplicates then does something with the non-duplicates, like deliver then to something else. That is exactly-once delivery.
  - stackghost 2y ago
    You wrote in the post: >This post was intended to be about human communication more than distributed systems or network protocols But resorting to technical minutiae as you have done doesn't seem germane to "human communication". Honestly, seeing such mental gymnastics just to avoid losing face on an internet argument is really disappointing.
    - lisper 2y ago
      What you call "technical minutiae" I call "the meanings of words", which is very germane to the matter of human communication.
  - mlyle 2y ago
    To discard the duplicates, you need to update your state based on the first message and consult that state for all subsequent messages. Someone must be delivered those messages for this to happen. If you say that someone can then pass you messages exactly once over a perfectly reliable channel, well.. sure. But the system still has to deal with duplicate delivery and update its state based on that. (And potentially must durably persist this state. And, then, if your application doesn't have exactly the same persistence/transactional boundaries as what's doing the deduping, you have problems...).
    - lisper 2y ago
      > To discard the duplicates, you need to update your state based on the first message and consult that state for all subsequent messages. Someone must be delivered those messages for this to happen. Yes, that's right. > If you say that someone can then pass you messages exactly once over a perfectly reliable channel, well.. sure. So you concede that you were wrong? > But the system still has to deal with duplicate delivery and update its state based on that. Well, part of the system does. But that part can be hidden behind an abstraction layer so that "you" can have exactly-once delivery doe some value of "you". > (And potentially must durably persist this state. And, then, if your application doesn't have exactly the same persistence/transactional boundaries as what's doing the deduping, you have problems...). Sure, but as I pointed out to you in the other thread in which we are engaged, that is irrelevant to the question of whether or not exactly-once delivery is possible.
      - mlyle 2y ago
        No, considering something at the end of a fault-free channel as the element of the distributed system being delivered to is silly. > we are engaged We are no longer engaged, because I've given up on talking to you. You can use "delivered" however you like by yourself, as you're eliminating everyone else's desire to listen to you. I think it's ridiculous that you're back to continue to poke this a day later. Find a hobby. Or read a textbook. I suggest Steen and Tanenbaum, which explains exactly-once semantics in distributed systems in a careful and thorough way (though this particular book doesn't say "delivery", unlike many others.