Our code is devided into two main loops. One loop is for leaders and followers and is where all of the main programming features happen. This is where appends are sent and received, puts acked and communicated to replicas. Heartbeats sent, and election timers checked. We then have a separate loop for candidates. This loop is slimmer and contains all of the code that deals with a candidate actively being elected. We have different cases in the code of each loop based on our replica's state (a simple enumeration). We then call functions that do what is required with the replica's given state. This part of the design makes dealing with all the cases very simple since we can simply assert that we are in a given case at the beginning of certain functions and not have to worry about them being called in incorrect circumstances. However, this meant that we had some difficulties implementing new concepts because we specificially had to make functionality for all three cases, which made fixing the bugs we discovered quite a pain. We discovered the bugs and tested our code through the included simulator and all the included test files. We did not make any of our own test files, as simply running the included tests and printing out what was happening was more than enough for us to create our raft implementation.
-
Notifications
You must be signed in to change notification settings - Fork 0
atulyamiglani/raft
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
About
A distributed key value store, using the raft protocol
Resources
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published