4 ms·

> Persistent connections with exactly-once messaging. Disconnection is just seen as long latency. Bullshit. https://groups.csail.mit.edu/tds/papers/Lynch/jacm

• rhencke 9y ago
  Urbit claims, like you, exactly-once messaging is impossible: https://news.ycombinator.com/item?id=14666015 https://news.ycombinator.com/item?id=14666015 But that doesn't mean we can't provide systems where, for all practical purposes, it is a guarantee. Another way to think about it: SHA1 cannot provide a unique hash for every possible set of content - there are overlaps. This is the pigeonhole principle. Yet, we have entire systems designed around assuming SHA1 is and will always be a unique hash for a piece of content (Git), and, for all practical purposes, it is a guarantee good enough to work despite that.
  • occultist_throw 9y ago
    >Urbit claims, like you, exactly-once messaging is impossible: https://news.ycombinator.com/item?id=14666015 https://news.ycombinator.com/item?id=14666015 >But that doesn't mean we can't provide systems where, for all practical purposes, it is a guarantee. Nuh huh. Dont you play wordgames with me. Exactly-once messaging is PROVEN impossible. And I, unlike the rest of you Urbiters, actually use standard terminology when understanding the last of 60 years of CS. > [Blablabla unrelated blather] Your point?
    • rhencke 9y ago
      From all reference I have read, the phrase "exactly-once messaging" does not have a strict technical definition. Neither of your links define or use the exact term "exactly-once messaging". If you can point me to a definition of this specific phrase's standard terminology, I would be grateful. But, I cannot find one. I don't understand why you address me with such a hostile tone. What have I done to deserve this? You accuse me of playing word games, but this is not my intent. I am just trying to have a conversation about the technical aspects of a system.
• pcmonk 9y ago
  From the second link: > FLP and the Two Generals Problem are not design complexities, they are impossibility results. Two generals, in its impossible form, isn't applicable here. For example, this proof[0] depends on the deterministic form being impossible to solve in a finite number of messages. But why would we care about doing it in a finite number of messages? By that measure, at-least-once delivery is impossible too, yet neither you nor the blogger seem to have a problem with that. The solution is easy and common: send a message, ack new messages, retry if you don't receive an ack, never ack an ack, and always ack a dupe. As long as you aren't disconnected forever, this will give you at least once delivery. FLP only applies in the case of faulty processes. Specifically, FLP arises because the faulty process must either (1) ack the message before handling it, or (2) handle it before acking it. (1) fails if it crashes after acking before handling, causing it to forget it ever received the message (at-most-once). (2) fails if it handles the message, but doesn't persist that fact to disk, so that when the dupe is received it doesn't know it already handled it (at-least-once). Urbit processes events transactionally (like a database), so you're guaranteed that if you received an ack it's because the other person has persisted that message or its results, and it won't forget about (i.e. they've persisted any state changes related to it). No faulty process, no problem. FLP impossibily doesn't apply. I suggest actually learning about proposed solutions to problems rather than recalling that someone convinced you they were impossible to solve. Proofs are powerful because they're incontrovertibly true, but they only apply if their conditions are met. [0] https://en.wikipedia.org/wiki/Two_Generals%27_Problem#Proof https://en.wikipedia.org/wiki/Two_Generals%27_Problem#Proof