One Comment

  1. Pavel

    I’m implementing this protocol myself and encountered this problem.

    Besides some inconsistency between what paper says about lazy voting and what reference implementation does (the latter only records one lazy vote, and replaces it each time when a lower term vote arrives, within the permitted window), there is the obvious problem with a ‘run-away candidate(s)’ you stated (it can even happen without network splitting because of election time-out randomization).

    What I was thinking about, is a mechanism of telling those run-aways: “Hey, dude, catch with us!”. I’m still in the process of thinking about details, because it can easily open a vector for an attack.

    The idea is to record last term with the leader and allowing looking back in the interval [lastLeaderTerm, myTerm] under certain conditions, e.g. when myTerm > lastLeaderTerm + H.

    Two cases:
    1. The cluster has a leader. Catch an AppendEntries from a server. Then request it’s quorum, as in protocol. Possible problem is replay attack from a byzantine server that was a leader in [lastLeaderTerm, myTerm]. This shouldn’t be a problem if committed entries are not overwritten (it should be taken care of). Other than that, it reproduces historical advancement of the protocol. If a newer leader is alive and reachable, the process will repeat itself.

    2. The cluster does not have a leader. Then RequestVote RPCs are flying around, and the node to adjust itself to the median term among them after it has a quorum of messages from different senders. Only requests with term higher than lastLeaderTerm are considered.

    This should work both forward and backward, and should retain log prefix property since any quorum will be a real quorum for a term higher than node’s thus the node will make progress adjusting its lastLeaderTerm. Under regular conditions the protocol is unchanged.

    What do you think?

Leave a Reply