AllConcur: Leaderless Concurrent Atomic Broadcast

Re:AllConcur: Leaderless Concurrent Atomic Broadcast by cioc on Friday August 26, 2016 @12:09PM (#12367183)

Paper's network assumptions:

"We assume a model of reliable communication—messages cannot be lost (only delayed). This is a reasonable assumption if we consider a reliable protocol, such as TCP."

Paxos network assumptions:

"Messages can take arbitrarily long to be delivered, can be duplicated, and can be lost, but they are not corrupted." - http://research.microsoft.com/en-us/um/people/lamport/pubs/p...

[ Parent | on HN ]

Re:AllConcur: Leaderless Concurrent Atomic Broadcast by coldcode on Friday August 26, 2016 @12:18PM (#12367245)

Not really fair to compare to Paxos if the network assumption is different.

[ Parent | on HN ]

Re:AllConcur: Leaderless Concurrent Atomic Broadcast by mperham on Friday August 26, 2016 @12:13PM (#12367214)

Sounds like Paxos could be implemented on top of UDP whereas AllConcur requires TCP?

[ Parent | on HN ]

Re:AllConcur: Leaderless Concurrent Atomic Broadcast by cioc on Friday August 26, 2016 @12:20PM (#12367272)

Duplicated and lost messages will happen in practice - TCP attempts to build reliable communication on an unreliable medium. Not clear from the paper if this matters.

I think the larger misunderstanding of the paper is the requirement that paxos have a leader - lamport's synod algorithm does not require a leader, the leader is an optimization!

[ Parent | on HN ]

Re:AllConcur: Leaderless Concurrent Atomic Broadcast by grogers on Friday August 26, 2016 @05:14PM (#12369350)

Without a long-lived leader, the performance would be so bad that I doubt there is a single production implementation that doesn't use that optimization.

[ Parent | on HN ]