Computer Science › Software + Distributed Computing
Every lab in this discipline runs its replicated systems over a simulated network, not a real one, and this first lab builds that simulator from scratch: a basic RPC layer plus a transport that can be told, on command, to delay a message, drop it silently, reorder it, or cut a specific pair of nodes off from each other entirely, the same simulate-first-then-break-it approach MIT's own 6.5840 course provides ready-made for its students, built here deliberately by hand instead so its actual mechanics, not just its API, are understood before every later lab in this discipline depends on it.
This lab implements the first quarter of Raft, matching MIT 6.5840's own Lab 3A exactly: RequestVote RPCs, randomized election timeouts, and the term-based logic that ensures at most one leader per term, run against Lab 1's simulator with real, repeatable failure scenarios (an isolated leader, a killed leader, a network too unreliable to elect anyone) rather than a diagram-only description of how election is supposed to work.
Raft's randomized election timeout is a direct, practical answer to a specific physical-clock problem this lab makes concrete instead of theoretical: real machine clocks drift relative to each other, so a fixed, identical timeout on every node would let two followers time out and start an election in the same instant far too often, splitting votes and stalling progress. This lab instruments the Lab 3 implementation to inject artificial clock skew and to sweep the election timeout's randomization window down toward zero, measuring, empirically, the point at which spurious, unnecessary elections start to dominate and leader stability collapses, turning the Raft paper's own stated timing requirements into a number actually measured, not just read.
This lab extends the elected leader from the previous lab into a real replicated log, implementing AppendEntries RPCs, the leader's per-follower nextIndex bookkeeping, and the majority rule that advances the commit index, matching MIT 6.5840's Lab 3B, and specifically forces the log-inconsistency-repair path that theory alone rarely makes concrete: killing and restarting followers mid-stream until a follower's log has genuinely diverged from the leader's, then verifying the implementation actually walks it back into agreement rather than merely working on the easy, no-failure path.
A Raft server that loses its term, vote, and log the instant it crashes can vote twice in the same term after restarting, silently violating the one-vote-per-term safety property this whole protocol depends on; this lab implements persistence of exactly the state Raft's own safety argument requires be durable, and its real test is a deliberate, repeated cycle of killing every server in the cluster simultaneously (a total power failure, not just one node's crash) and confirming the whole system resumes correctly from disk, matching MIT 6.5840's Lab 3C.
An always-growing, never-truncated Raft log is a real, practical failure waiting to happen, not just an inefficiency, since a follower that falls far enough behind eventually cannot catch up by replaying a log too large to hold in memory or replay in reasonable time; this lab implements periodic snapshotting and the InstallSnapshot RPC that lets a badly lagging follower jump straight to a recent state instead, matching MIT 6.5840's Lab 3D, tested by deliberately starving one follower of AppendEntries for long enough that only a snapshot, not ordinary log replication, can bring it current again.
Before replication enters the picture at all, this lab builds a single-node Put/Get/Append key-value server over Lab 1's own unreliable transport, and immediately confronts the concrete problem that transport creates: a client whose RPC reply was lost cannot tell whether its request never arrived or arrived and succeeded, so it retries, and a naive server executes that retried write twice. Implementing duplicate detection (a client and request ID stamped on every RPC, a server-side table remembering which IDs have already been applied) is what actually turns "at-least-once delivery from an unreliable network" into the at-most-once execution guarantee client code can safely rely on.
This lab is where "o banco replicado" this discipline is named for actually gets built: the Put/Get/Append key-value service from Lab 2 rebuilt on top of the complete Raft implementation from Labs 3-6, so every write is committed through the log before it is applied and every read reflects the latest committed state, matching MIT 6.5840's Lab 4 in full, including its actual correctness bar, linearizability verified under randomized concurrent clients, server crashes, and partitions all in the same test run, not merely correctness under the easy case of no concurrency and no failures.
This capstone runs the finished, linearizable KV-on-Raft store from Lab 7 through a single, combined chaos scenario, network partition splitting the cluster into a majority and a minority side, concurrent crashes and restarts on top of that partition, an unreliable, packet-dropping transport throughout, and injected clock skew from Lab 8 all at once, matching the real, combined test conditions MIT 6.5840's own hardest Lab 4 tests run under, and requires writing up what was actually observed: the minority partition correctly stalls rather than serving stale writes, exactly the availability-for-consistency trade this whole curriculum's CAP and PACELC theory already predicted, now confirmed against a system built by hand rather than taken on faith.
Part of the Computer Science curriculum.
Every lab in this discipline runs its replicated systems over a simulated network, not a real one, and this first lab builds that simulator from scratch: a basic RPC layer plus a transport that can be told, on command, to delay a message, drop it silently, reorder it, or cut a specific pair of nodes off from each other entirely, the same simulate-first-then-break-it approach MIT's own 6.5840 course provides ready-made for its students, built here deliberately by hand instead so its actual mechanics, not just its API, are understood before every later lab in this discipline depends on it.
This lab implements the first quarter of Raft, matching MIT 6.5840's own Lab 3A exactly: RequestVote RPCs, randomized election timeouts, and the term-based logic that ensures at most one leader per term, run against Lab 1's simulator with real, repeatable failure scenarios (an isolated leader, a killed leader, a network too unreliable to elect anyone) rather than a diagram-only description of how election is supposed to work.
Raft's randomized election timeout is a direct, practical answer to a specific physical-clock problem this lab makes concrete instead of theoretical: real machine clocks drift relative to each other, so a fixed, identical timeout on every node would let two followers time out and start an election in the same instant far too often, splitting votes and stalling progress. This lab instruments the Lab 3 implementation to inject artificial clock skew and to sweep the election timeout's randomization window down toward zero, measuring, empirically, the point at which spurious, unnecessary elections start to dominate and leader stability collapses, turning the Raft paper's own stated timing requirements into a number actually measured, not just read.
This lab extends the elected leader from the previous lab into a real replicated log, implementing AppendEntries RPCs, the leader's per-follower nextIndex bookkeeping, and the majority rule that advances the commit index, matching MIT 6.5840's Lab 3B, and specifically forces the log-inconsistency-repair path that theory alone rarely makes concrete: killing and restarting followers mid-stream until a follower's log has genuinely diverged from the leader's, then verifying the implementation actually walks it back into agreement rather than merely working on the easy, no-failure path.
A Raft server that loses its term, vote, and log the instant it crashes can vote twice in the same term after restarting, silently violating the one-vote-per-term safety property this whole protocol depends on; this lab implements persistence of exactly the state Raft's own safety argument requires be durable, and its real test is a deliberate, repeated cycle of killing every server in the cluster simultaneously (a total power failure, not just one node's crash) and confirming the whole system resumes correctly from disk, matching MIT 6.5840's Lab 3C.
An always-growing, never-truncated Raft log is a real, practical failure waiting to happen, not just an inefficiency, since a follower that falls far enough behind eventually cannot catch up by replaying a log too large to hold in memory or replay in reasonable time; this lab implements periodic snapshotting and the InstallSnapshot RPC that lets a badly lagging follower jump straight to a recent state instead, matching MIT 6.5840's Lab 3D, tested by deliberately starving one follower of AppendEntries for long enough that only a snapshot, not ordinary log replication, can bring it current again.
Before replication enters the picture at all, this lab builds a single-node Put/Get/Append key-value server over Lab 1's own unreliable transport, and immediately confronts the concrete problem that transport creates: a client whose RPC reply was lost cannot tell whether its request never arrived or arrived and succeeded, so it retries, and a naive server executes that retried write twice. Implementing duplicate detection (a client and request ID stamped on every RPC, a server-side table remembering which IDs have already been applied) is what actually turns "at-least-once delivery from an unreliable network" into the at-most-once execution guarantee client code can safely rely on.
This lab is where "o banco replicado" this discipline is named for actually gets built: the Put/Get/Append key-value service from Lab 2 rebuilt on top of the complete Raft implementation from Labs 3-6, so every write is committed through the log before it is applied and every read reflects the latest committed state, matching MIT 6.5840's Lab 4 in full, including its actual correctness bar, linearizability verified under randomized concurrent clients, server crashes, and partitions all in the same test run, not merely correctness under the easy case of no concurrency and no failures.
This capstone runs the finished, linearizable KV-on-Raft store from Lab 7 through a single, combined chaos scenario, network partition splitting the cluster into a majority and a minority side, concurrent crashes and restarts on top of that partition, an unreliable, packet-dropping transport throughout, and injected clock skew from Lab 8 all at once, matching the real, combined test conditions MIT 6.5840's own hardest Lab 4 tests run under, and requires writing up what was actually observed: the minority partition correctly stalls rather than serving stale writes, exactly the availability-for-consistency trade this whole curriculum's CAP and PACELC theory already predicted, now confirmed against a system built by hand rather than taken on faith.