SwiftPaxos: Fast Geo-Replicated State Machines
This repository contains the prototype implementation of SwiftPaxos, a new state-machine replication protocol for geo-distributed systems.
SwiftPaxos is a faster Paxos without compromises.
In the best case, it executes a state-machine command in two message delays (one round-trip), and three otherwise.
SwiftPaxos was presented at the 21st USENIX Symposium on Networked Systems Design and Implementation (NSDI '24).
Installation
git clone https://github.com/provok1ng/sp.git
cd swiftpaxos
go install github.com/provok1ng/sp
Implemented protocols
Protocol |
Comments |
SwiftPaxos |
See our NSDI'24 paper for the full details. |
Paxos |
The classic Paxos protocol. |
N2Paxos |
All-to-all variant of Paxos. |
CURP |
CURP implemented over N2Paxos. |
Fast Paxos |
Fast Paxos with uncoordinated collision recovery. |
EPaxos |
A corrected version of EPaxos. |
This software is based on the Egalitarian Paxos code base, as well as the corrections made here.
Usage
participants
There are three types of participants: master, servers and clients.
The servers and clients implement the protocol logic.
The master maintains the configuration of the system.
deployment configuration
To setup a run, the participants read deployment configuration file.
See aws.conf for an example of configuration file for AWS EC2.
launching a participant
Master:
swiftpaxos -run master -config conf.conf
Server:
swiftpaxos -run server -config conf.conf -alias server_name
Client:
swiftpaxos -run client -config conf.conf -alias client_name
command line options
-alias alias
An alias of this participant
-config file
Deployment config file (required)
-latency file
Latency config file
-log file
Path to the log file
-protocol protocol
Protocol to run. Overwrites protocol field of the config file
-quorum file
Quorum config file
-run participant
Run a participant
See quorum.conf and latency.conf for an example of quorum and latency configuration files.
Flint
To have an idea on how different replication protocols would compare, we wrote a tool named Flint.
Flint takes as input a set of AWS regions.
It computes the expected latencies and estimates how the protocols perform in such a deployment.