Initial version of peer docs

This commit is contained in:
Dmitry Shulyak 2018-03-27 15:39:45 +03:00 committed by Dmitry Shulyak
parent 37f19d813c
commit 5e5e497822
3 changed files with 52 additions and 0 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 26 KiB

52
_assets/docs/discovery.md Normal file
View File

@ -0,0 +1,52 @@
Discovery v5 usage in status-go
===============================
Capability-based discovery will be using two mechanisms from discv5 go-ethereum
implementation. Topic registration and topic search.
Registration
------------
![alt text](artifacts/v5reg.png)
Every topic registration spawns two interdependent loops:
1. Node that registers itself as a topic provider will periodically send topics
to the peers.
2. Second loop advertises itself to peers in the network.
It does so by requesting peers from known peers and sending ping request to them.
As a result all peers in the network will learn about new node faster.
Search
------
![alt text](artifacts/v5search.png)
Search request spawns single loop for every searched topic. This loop
request peers from known peers (starting from one-self) and then requests
from them nodes that are registered as a topic provider.
We can control how often this loop wil run, more about it in the next section.
Peer pool in status-go
----------------------
Peer pool uses search mechanism described above to find peers in a timely manner
without using a lot of resources in the long run. It achieves it by introducing
two modes of synchronization:
1. Fast mode.
Peer will run search loop quite often (every 500ms at the time of writing) with the
goal to visit as much nodes as possible and once it will find minimum amount of
peers with required capability it will swich to slow mode.
2. Slow mode.
This mode might be useful to get information about new peers that can be used
later if initial set of peers will dissapear. Should run once in a 10m-30m.
However finding peers even with fast mode can take noticeable amount of time,
which is fine if node is a long-running, but will be a huge problem on a mobile
device. To workaround such problem we will introduce a leveldb cache that will
maintain a list of peers that was used by a device before it went offline.
Another important detail of a peer pool is a support of min and max amount of peers:
- min is required to switch from fast to slow sync mode
- max is an upper limit that can be used by a single node