pcattori
commented
10 years ago @brando90 1) prepare_epoch(e, seq) are replied with a map of responses (as in https://github.com/brando90/RoadRunner/commit/7850700a6ef2f4758e1ffeab8c7849be9a8dacca). So a prepare_epoch will receive many OK's and many rejects from the same server, since that server is batching its replies for all acceptors it has with sequence number >= seq.
We do not actually need to know the id of the leader since our leader election and catch up procedures do not depend on the leaders id.
2) There is no such thing as a correct leader or a wrong leader anymore. Since our leader election protocol is not implemented as a consensus, it does not break correctness to have more than one leader. Of course, more than one leader makes for contention (i.e. dueling proposers) so we'd like to avoid multiple leaders in the common case. N'ack-ing/rejecting occurs due to basic paxos mechanisms (e.g. if the proposal number for a prepare is lower than the accepted proposal number for this acceptor, or if the proposal number for an accept is lower than the prepare proposal number for this acceptor).
What different and how many different type of nacks (and nack rpc handlers) do we need?
1) For rejecting a prepare_epoch(e, seq), right? Should we also respond with who we believe is the actual leader and the highest local min we know about?
2) We also need to nack accept's from "wrong" leaders. Right? How are we doing this? When a wrong accept is received it means that he thinks he is the leader but he really is not. Thus, shouldn't we just tell him who the real leader is? Also, do we need to piggy-back any other info like local mins?