2014-06-25 11:58:34 -07:00
## Channels
2014-06-26 20:51:19 -07:00
Each peer connection is multiplexed into channels.
2014-06-25 11:58:34 -07:00
< hr / >
### Default channel
The default channel is used to communicate state changes, pings, peer exchange, and other automatic internal messages that all P2P protocols would want implemented.
2014-06-24 23:49:06 -07:00
2014-06-24 23:58:38 -07:00
< table >
2014-06-25 11:58:34 -07:00
< tr >
< td > < b > Channel< / b > < / td >
< td > ""< / td >
< / tr >
2014-06-24 23:58:38 -07:00
< tr >
2014-06-25 11:58:34 -07:00
< td > < b > Messages< / b > < / td >
2014-06-24 23:58:38 -07:00
< td >
< ul >
2014-06-25 11:58:34 -07:00
< li > PingMsg/PongMsg< / li >
2014-06-24 23:58:38 -07:00
< li > PeerExchangeMsg< / li >
2014-06-25 11:58:34 -07:00
< li > RefreshFilterMsg< / li >
2014-06-24 23:58:38 -07:00
< / ul >
< / td >
< / tr >
< / table >
2014-06-25 11:58:34 -07:00
< hr / >
2014-06-24 23:49:06 -07:00
2014-06-25 11:58:34 -07:00
### Block channel
2014-06-24 23:49:06 -07:00
2014-06-25 11:58:34 -07:00
The block channel is used to propagate block or header information to new peers or peers catching up with the blockchain.
2014-06-24 23:49:06 -07:00
2014-06-24 23:58:38 -07:00
< table >
2014-06-25 11:58:34 -07:00
< tr >
< td > < b > Channel< / b > < / td >
< td > "block"< / td >
< / tr >
2014-06-24 23:58:38 -07:00
< tr >
2014-06-25 11:40:26 -07:00
< td > < b > Messages< / b > < / td >
2014-06-24 23:58:38 -07:00
< td >
< ul >
< li > RequestMsg< / li >
< li > BlockMsg< / li >
< li > HeaderMsg< / li >
< / ul >
< / td >
< / tr >
2014-06-26 20:51:19 -07:00
< tr >
< td > < b > Notes< / b > < / td >
< td >
Nodes should only advertise having a header or block at height 'h' if it also has all the headers or blocks less than 'h'. Thus for each peer we need only keep track of two integers -- one for the most recent header height 'h_h' and one for the most recent block height 'h_b', where 'h_b' < = 'h_h'.
< / td >
< / tr >
2014-06-24 23:58:38 -07:00
< / table >
2014-06-25 11:58:34 -07:00
< hr / >
2014-06-24 23:49:06 -07:00
2014-06-25 11:58:34 -07:00
### Mempool channel
2014-06-24 23:49:06 -07:00
2014-06-25 11:58:34 -07:00
The mempool channel is used for broadcasting new transactions that haven't yet entered the blockchain. It uses a lossy bloom filter on either end, but with sufficient fanout and filter nonce updates every new block, all transactions will eventually reach every node.
2014-06-24 23:49:06 -07:00
2014-06-24 23:58:38 -07:00
< table >
2014-06-25 11:58:34 -07:00
< tr >
< td > < b > Channel< / b > < / td >
< td > "mempool"< / td >
< / tr >
2014-06-24 23:58:38 -07:00
< tr >
2014-06-25 11:40:26 -07:00
< td > < b > Messages< / b > < / td >
2014-06-24 23:58:38 -07:00
< td >
< ul >
< li > MempoolTxMsg< / li >
< / ul >
< / td >
< / tr >
2014-06-26 20:51:19 -07:00
< tr >
< td > < b > Notes< / b > < / td >
< td >
Instead of keeping a perfect inventory of what peers have, we use a lossy filter.< br / >
Bloom filter (n:10k, p:0.02 -> k:6, m:10KB)< br / >
Each peer's filter has a random nonce that scrambles the message hashes.< br / >
The filter & nonce refreshes every new block.< br / >
< / td >
< / tr >
2014-06-24 23:58:38 -07:00
< / table >
2014-06-25 11:58:34 -07:00
< hr / >
### Consensus channel
2014-06-24 23:58:38 -07:00
2014-06-25 11:58:34 -07:00
The consensus channel broadcasts all information used in the rounds of the Tendermint consensus mechanism.
2014-06-24 23:58:38 -07:00
< table >
2014-06-25 11:58:34 -07:00
< tr >
< td > < b > Channel< / b > < / td >
< td > "consensus"< / td >
< / tr >
2014-06-24 23:58:38 -07:00
< tr >
2014-06-25 11:40:26 -07:00
< td > < b > Messages< / b > < / td >
2014-06-24 23:58:38 -07:00
< td >
< ul >
< li > ProposalMsg< / li >
< li > VoteMsg< / li >
< li > NewBlockMsg< / li >
< / ul >
< / td >
< / tr >
2014-06-26 20:51:19 -07:00
< tr >
< td > < b > Notes< / b > < / td >
< td >
How do optimize/balance propagation speed & bandwidth utilization?
< / td >
< / tr >
2014-06-24 23:58:38 -07:00
< / table >
2014-06-27 17:01:59 -07:00
## Resources
* http://www.upnp-hacks.org/upnp.html