-
Notifications
You must be signed in to change notification settings - Fork 27
Types
A Proposal
is the subject on which all nodes need to reach consensus.
Proposal {
Payload []byte
Header []byte
Metadata []byte
VerificationSequence uint64
}
A View
has a designated leader and followers. It runs all three phases (prePrepare, prepare, and commit) on the proposals. It can abort on demand.
View {
Propose(p Proposal)
OnReceive(m Message)
Abort()
}
The Consensus
runs the different views, proposes values and delivers the decisions. It also aborts views when they must be changed.
Consensus {
ViewBuilder
View
ViewChanged(id int)
}
The ViewBuilder
helps Consensus
building new views.
ViewBuilder {
BuildView(id int, members []int, d Decider, vc ViewChanger) View
}
The Decider
delivers the decisions (agreed proposals and signatures) to the Consensus
.
Decider {
Decide(p Proposal, signatures []Signature)
}
The ViewChanger
collects the requests to change the current view and runs the view change protocol when needed. It informs the Consensus
of the new view.
ViewChanger {
OnReceive(m Message)
}
The Timeouter
is used to track timing. It is started with a given duration and a function to call if the duration passes. When it is started it returns a cancel call to use if an abort of the timeout is required.
Timeouter {
StartTimer(Duration, func) Cancel
}
A Signature
used to prove that a node with a given Id
signed something.
Signature {
Id uint64
Value []byte
}
A RequestPool dispatches request submissions by the application layer, and tracks their inclusion into blocks, and raises a re-transmission of them to the cluster upon a first timeout, and complains to the view changer upon a second timeout.
RequestPool {
Submit(request []byte)
}
A Synchronizer reaches the cluster nodes and fetches blocks in order to sync the replica's state. An invocation of Sync() blocks indefinitely until the replica's state is synchronized to the latest verification sequence.
Synchronizer {
Sync()
}