Anton Kaliaev 7fa12662c4
check whatever we can read from the channel
```
panic: interface conversion: interface {} is nil, not types.TMEventData

goroutine 7690 [running]:
github.com/tendermint/tendermint/consensus.waitForAndValidateBlock.func1(0xc427727620, 0x3)
        /go/src/github.com/tendermint/tendermint/consensus/reactor_test.go:292 +0x62b
created by github.com/tendermint/tendermint/consensus.timeoutWaitGroup
        /go/src/github.com/tendermint/tendermint/consensus/reactor_test.go:349 +0xa4
exit status 2
FAIL    github.com/tendermint/tendermint/consensus      38.614s

```
2017-11-10 18:16:31 -05:00
..
2017-10-30 00:32:22 -05:00
2017-10-30 00:32:22 -05:00
2017-11-09 13:37:29 -05:00
2016-08-09 20:31:53 -04:00
2017-10-30 00:32:23 -05:00
2017-10-30 00:32:22 -05:00
2017-10-30 00:32:22 -05:00
2017-10-30 00:32:22 -05:00
2017-07-20 00:59:28 -04:00
2017-10-04 16:40:45 -04:00
2017-10-25 21:54:56 -04:00

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.