Students may opt in for final project. Each team should be with 2-3 students. The score of final project will replace the worst score of three in-class quizzes or lab 3.
Signup link: https://forms.gle/F5X6YKh7jmcdM2JJ9
10/30: Final project signup deadline.
10/31: initial project proposal due
10/29-11/7: meeting with instructor
11/7: Project approval/rejection decision out
11/9: Revised proposal due
12/5: Project due
Demo during lecture time
Code & report due @ 12pm
Project proposal document. 1 page US letter, 10 pt or larger.
Demo: 10-20 mins presentation, depending on the number of teams
Code: submit your implementation on github classroom
Report: 4-5 page report, describing design, implementation, and evaluation. (example: A Byzantine Fault Tolerant Raft, stanford 22spring)
I highly suggest to discuss with me if you are interested in final project. You may come to my office hours to build some project ideas.
Here are some ideas you might be interested in for projects. This list is by no means exhaustive (some of them are borrowed from David Mazieres).Â
Extending Raft (may reuse lab2) to tolerate byzantine faults.
Applying CURP-like mechanism to Raft (may reuse lab 2).
Distributed protocols such as 2PC and Paxos are (1) short, (2) really hard to get right because of failures and uncertainty. Build a simple system that takes an implementation of these protocols and systematically explores their behavior in the face of crashes and network partitioning. See here for an example of how to do this for file systems.
Extending RIFL to provide exactly-once semantice for chain of microservices
Extending RIFL to provide exactly-once semantice for Spanner-like systems that provide migrations + SMR.
Build a distributed profiler that allows you to observe where time really goes in a distributed system. You should use it to spot bottlenecks in at least one existing distributed system.
Build a checking infrastructure than can plug into the many different RAFT implementations and find protocol errors. The nice trick you can use here is that you do not have to specify correctness: each of the protocols must do the same observable action given the same sequence of crashes, partitions, recoveries. You may want to look at what Kyle Kingsbury has done with Jepsen.
Build a clean, simple implementation of view stamped replication based on the updated Liskov paper that can be dropped into distributed systems in a way analogous to RAFT.
Raspberry/pi is a very popular embedded computing platform. Build a distributed system using r/pi nodes and some interesting cheap hardware. More ambitious: build a clean, simple "bare-metal" toolkit on r/pi that allows people to easily build such systems.
Build a simple, automatic distributed-parallel make implementation. Most makefiles are broken with spurious dependencies (slow) and missing dependencies (incorrect). Fortunately you can infer true dependencies automatically: kick off an existing (broken) build, intercept every "open()" system call to see which other files a given file depends on (e.g., all the files it #includes). Build a lightweight distributed system that does parallel distributed builds using these dependencies.
Build a large file store, like GFS, and possibly using RAID like Zebra.
Build a simplified version of a synchronization service like Google's Chubby.
Build a highly-available, replicated DNS server that uses Paxos to ensure consistency of updates.
Build a system-call or message-level interposition library that can be slipped underneath an existing networked server and transparently be used to replicate these services so that they can survive failure and network partitioning. (Something similar but more complicated that what you would build: parrot.)
Build a file synchronization tool like tra.
Build a raftscope-like visualization tool for a different protocol.