pagwin-fedora / cpp_raft_impl Goto Github PK

make relevant calls to the raft api decided via #7 via information gotten over the relevant network/unix socket protocol

See

• #16
• #17
• #18
• #19
• #20

Raft maintains a log of changes that are to be made to a state machine when those changes are committed they should be applied to that state machine

See sub issues

• #3
• #4
• #5

Figure out the shape of the public API of the raft algorithm implementation so it can be implemented confidently alongside the IO

Candidates should increment their term and start a new election if they can't get majority within a certain timeframe

If a leader gets a message from a leader or candidate with a higher term number it needs to demote to follower

In all likelihood this'll just be a vector which is appended to which maps relatively easily to what Raft is supposed to do, specifics could allow for removal and adding of elements to it but at minimum just having a growing list will be sufficient

When a candidate is seeking majority there are situations involving it's current log state where it shouldn't continue as a candidate. Namely it may not have committed log entries in it's log in which case it should not consider itself as having achieved majority

In raft the leader is considered the source of all changes, and the source of truth is the list of committed logs which the leader decides on when it's communicated the logs entry to at least half of instances

If the log is found to be stale the candidate needs to change to a follower

Sometimes logs will be stale due to the election of a new leader who will send message(s) indicating as much #5 in these circumstances logs need to be deleted

Followers need to begin an election when a random amount of time has elapsed to handle a situation where the leader fails

If a majority of votes is acquired then a candidate should change to the leader state

When a leader is given a new log entry it needs to send it to followers and delete logs that shouldn't be present

See

• #11
• #13
• #14

The intended design of this project is to have all functionality of Raft be pure taking arguments as input and returning values as outputs without doing any network IO within the logic this is to allow that functionality to be handled elsewhere allowing for easier testing and swapping between different models of concurrency and IO as desired

• #7
• #8

When a node is a candidate it should go to all other known nodes and request votes trying to achieve majority