Initial version of peer docs
This commit is contained in:
parent
37f19d813c
commit
5e5e497822
Binary file not shown.
After Width: | Height: | Size: 22 KiB |
Binary file not shown.
After Width: | Height: | Size: 26 KiB |
|
@ -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
|
Loading…
Reference in New Issue