4 ms·
Apparently Marc is right about the need for more of this - the answer is that the kind of nasty timing of message losses that can render consensus impossible do
by dgacmu 12y ago
Apparently Marc is right about the need for more of this - the answer is that the kind of nasty timing of message losses that can render consensus impossible don't happen, by and large, for very long in practice. It's not necessary to have Byzantine failures to prevent consensus, it's a consequence of the arbitrary network behavior allowed in an asynchronous communications model.
I should add this question to one of my exams and see if my students get it right. I'll be a little grumpy if they don't, but it's a great question. :)
- chubot 12y agoWhat's an example of "timing of message losses" that would make consensus impossible? I didn't think say Paxos depended on any such assumptions. I suppose you can mathematically construct some kind of non-total message loss such that Paxos would never make progress. But that kind of message loss won't persist forever in a real system... it would basically be message loss with knowledge of the algorithm?
- grogers 12y agoRacing proposers cause paxos to fail to converge. A: Prepare(1) B: Prepare(2) A: Accept(1, Va) # fails. A: Prepare(3) B: Accept(2, Vb) # fails. Etc... In practice randomized backoffs when this happens causes it to converge extremely fast, but the exact right situation COULD cause it to delay forever. Don't lose sleep over it though.
- chubot 12y agoYeah that is basically what I was imagining, but there's no failure condition that matches that in reality. You might get unlucky and fail to converge for 10 iterations, but not for say 10,000. It is sort of Byzantine in that the "system" is inserting very specific message losses with knowledge of the algorithm.