dc0e8de9b0
so they can be used in rpc/core/types/responses.go.
```
So, it seems like we could use the actual structs here, but we don't want to have to import consensus to get them, as then clients are importing too much crap. So probably we should move some types from consensus into consensus/types so we can import.
Will these raw messages be identical to:
type ResultDumpConsensusState struct {
RoundState cstypes.RoundState
PeerRoundStates map[string]cstypes.PeerRoundState
}
```
https://github.com/tendermint/tendermint/pull/724#discussion_r143598193
|
||
|---|---|---|
| .. | ||
| test_data | ||
| types | ||
| README.md | ||
| byzantine_test.go | ||
| common.go | ||
| common_test.go | ||
| mempool_test.go | ||
| reactor.go | ||
| reactor_test.go | ||
| replay.go | ||
| replay_file.go | ||
| replay_test.go | ||
| state.go | ||
| state_test.go | ||
| ticker.go | ||
| version.go | ||
| wal.go | ||
README.md
The core consensus algorithm.
- state.go - The state machine as detailed in the whitepaper
- reactor.go - A reactor that connects the state machine to the gossip network
Go-routine summary
The reactor runs 2 go-routines for each added peer: gossipDataRoutine and gossipVotesRoutine.
The consensus state runs two persistent go-routines: timeoutRoutine and receiveRoutine. Go-routines are also started to trigger timeouts and to avoid blocking when the internalMsgQueue is really backed up.
Replay/WAL
A write-ahead log is used to record all messages processed by the receiveRoutine, which amounts to all inputs to the consensus state machine: messages from peers, messages from ourselves, and timeouts. They can be played back deterministically at startup or using the replay console.