lisper

53 ms·

811.
by lisper 2y ago
I was responding to this: > You can't get exactly once delivery using proposed solution in general case because you can not have infinite memory for dedupe. That is a specific criticism of a specific and highly oversimplified algori
812.
by lisper 2y ago
That may well be, but that's a very different question.
813.
by lisper 2y ago
The same way I ensure any behavior in a digital system. There are boundaries inside of which processes are presumed to be reliable, typically consisting of a CPU, memory busses, and attached non-volatile storage. If you don't assume
814.
by lisper 2y ago
> That's a little sloppy Yes, that is exactly my point. The only way you can make it non-sloppy is to define "delivery" as being something that happens exclusively upstream of deduping.
815.
by lisper 2y ago
> 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 p
816.
by lisper 2y ago
Yes, that is true. But why can't I choose to view "the system itself" as the thing that is on the other side of a de-duplicator? It feels to me like an argument over whether or not humans can fly. An unassisted human cannot
817.
by lisper 2y ago
> If you have duplicate things, then you've clearly been delivered more than one thing. Yes, that's true. But this doesn't turn on what "delivery" means, it turns on what "you" means. If "you&quo
818.
by lisper 2y ago
> referring to the delivery of the message to the system itself And how do you define "the system itself"?
819.
by lisper 2y ago
It is hard to make the point that "exactly-once delivery" is not a technical term without referring to it. If you think it is a technical term, would you kindly point me to a definition? I'm particularly interested in lea
820.
by lisper 2y ago
You apparently missed this part: "Just for the sake of completeness I should point out that removing duplicates at the receiver is a pretty extreme oversimplification of what you would do in practice to provide exactly-once delivery.
821.
by lisper 2y ago
You apparently missed this: "Just for the sake of completeness I should point out that removing duplicates at the receiver is a pretty extreme oversimplification of what you would do in practice to provide exactly-once delivery. A com
822.
by lisper 2y ago
Author here. Most commenters still seem to be missing the point, despite the fact that I explicitly say this in the opening sentence: "This post is ostensibly about an obscure technical issue in distributed systems, but it's real
823.
Yes, you can have exactly-once delivery(blog.rongarret.info)
54 points by lisper 2y ago|133 comments
824.
Common Knowledge and Aumann's Agreement Theorem (2015)(scottaaronson.blog)
2 points by lisper 2y ago|0 comments
825.
by lisper 2y ago
> I gave two concrete examples. Neither of which was on point because they both ignored how exactly-once delivery can be done. > Read the two general's problem. The 2GP is not on point because it's about achieving consensus,
826.
by lisper 2y ago
> hopefully you understand that there's a pretty big mismatch here Yep. But on the other hand, 1) I have a Ph.D. in CS, and 2) I have yet to see anyone in this thread actually produce a reference to a reliable source to back up the
827.
by lisper 2y ago
> Change your words from "delivery" to "processing" and you in alignment with reality. You are not the first to say this, but so far no one has been able to explain what the difference between "delivery" and
828.
by lisper 2y ago
> exactly once _processing_ but not exactly once _delivery_ What exactly is the difference? What counts as "delivery"? How do you do "delivery" (on a computer) without doing at least some "processing"?
829.
by lisper 2y ago
What subtlety do you think I have failed to absorb?
830.
by lisper 2y ago
This proof is flawed: "Let’s assume that a protocol exists which guarantees that a recipient receives a message from the sender once and only once. Such a protocol could then solve the two generals problem! Representing the time of the
831.
by lisper 2y ago
> still vulnerable to two generals What makes you think the 2GP is relevant here? The 2GP has to do with coordination and consensus, not exactly-once delivery. > TCP is implemented in the kernel with a buffer, the kernel responds with
832.
by lisper 2y ago
Uh, what exactly do you think is "agreed" here? My claim is that idempotent processing can produce exactly-once delivery, and so the original claim that you "cannot have exactly-once delivery" is false.
833.
by lisper 2y ago
What makes you think the 2GP is relevant here? The 2GP has to do with coordination and consensus, not exactly-once delivery.
834.
by lisper 2y ago
What makes you think the 2GP is relevant here? The 2GP has to do with coordination and consensus, not exactly-once delivery.
835.
by lisper 2y ago
What makes you thin the 2GP is relevant here? 2GP has to do with coordination and consensus, not exactly-once-delivery. > you can simulate it with exactly once _processing_ What exactly do you think is the difference between "simul
836.
by 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 deli
837.
by lisper 2y ago
> What you need is for all sent messages to have unique IDs that will never repeat, and then log those. That's known as an idempotency token. So your problem is not really a problem because you yourself present the solution. The re
838.
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 ca
839.
by lisper 2y ago
OK, but you have to do a little extrapolating here because the claim is not that you can do exactly-once under all circumstances. That is obviously false because you can't do exactly-once in a situation where all comms are down indefi
840.
by lisper 2y ago
> But not 100%. Why not? > At some point, a counter move on the delivery has to be stored... -somewhere-. What is a "counter move on the delivery"?

More ›