tendermint/p2p/README.md

114 lines
2.5 KiB
Markdown
Raw Normal View History

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 />
2014-07-06 16:08:25 -07:00
### PEX channel
2014-06-25 11:58:34 -07:00
2014-07-06 16:08:25 -07:00
The PEX channel is used to exchange peer addresses.
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>
2014-07-06 16:08:25 -07:00
<td>"PEX"</td>
2014-06-25 11:58:34 -07:00
</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-07-06 16:08:25 -07:00
<li>pexRequestMsg</li>
<li>pexResponseMsg</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' &lt;= '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>
## Resources
* http://www.upnp-hacks.org/upnp.html