Proposal max proposal 1 rather ith node

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: node serves as proposer/acceptor/learner a client talks to the Paxos group as if it is talking to one server; it sends a request to any participant and they collectively vote on the sequence of client requests; reply back to the client when the action is committed (chosen, that is, accepted by a majority, and learned) 1) picking proposal #’s (for voting on which event goes into a particular slot in the sequence): I said the proposal # needs to be unique across all proposals, but doesn’t that require consensus? Proposal # = max proposal # + 1 ??? Rather: ith node making jth proposal among k nodes: Proposal # = j*k + i 2) picking a leader The basic Paxos algorithm selects a single value, such that regardless of failures, once a majority has accepted the value, all further proposals will yield the same value. So we can think of the value being “committed”, at the point when the majority accepts the value. Paxos algorithm may not make progress if there are two simultaneous proposers; also won’t make progress if there are zero proposers if multiple nodes are making proposals at the same time, each could issue a prepare message in turn that would prevent any acceptor from accepting the other node’s proposal. The natural solution is to always elect a leader first. Clients could then send their requests to the leader; the leader would then pick the order of operations, and have the Paxos replicas vote to concur on that order. However, can’t guarantee exactly one proposer! (without running paxos to elect the proposer!) The idea i...
View Full Document

This document was uploaded on 04/04/2014.

Ask a homework question - tutors are online