Raft Project 2 Review/Discussion (Winter 2020)

Lecture Notes for CS 190
Winter 2020
John Ousterhout

Click here for .cc file containing examples.
Lines of code: 2521, 2599, 2891, 2926, 3002, 3046, 3189, 3380, 3999
Everyone made improvements from Project 1.
- Deeper classes (simpler APIs, less specialization & information leakage)
- Better error detection and logging (but still more work to do)
- Synchronization much cleaner and simpler

Class Design: Together vs. Apart

Given various pieces of functionality, which belong together in the same class and which should be separated in different classes?
Key considerations:
- Separate general-purpose and special-purpose code
  - Over-specialization creates information leakage
- Combine things that are related, separate things that are not related
  - Do one thing at a time
- Do the whole job in one place
Examples:
- Raft server contains state machine for shell?
- Client main program also has code to communicate with Raft cluster?
- Communication libraries for server-server and client-server communication?
- Raft server also manages communication with clients?
- Log class also manages other persistent state such as term and vote?
- Command-line parser contains network address parser?
- 2 methods in one (raft9)
- Handling vote split between 2 methods (raft7)

Templating the entire RPC class on protobuf type is problematic
- Specializes it (can only handle one message type)
- Better alternatives:
  - Use templating only for send and receive methods
  - Or, base RPC class on blocks of bytes
- What's the problem with google::protobuf::Any?
Create helper classes (e.g. exceptions) as nested subclasses, not top-level classes (see example)
Heartbearts: several groups maintained the same interpretation as Project 1: no log data