github.com/status-im/status-go@v1.1.0/_assets/docs/discovery.md (about)

     1  Discovery v5 usage in status-go
     2  ===============================
     3  
     4  Capability-based discovery will be using two mechanisms from discv5 go-ethereum
     5  implementation. Topic registration and topic search.
     6  
     7  
     8  Registration
     9  ------------
    10  ![alt text](artifacts/v5reg.png)
    11  
    12  Every topic registration spawns two interdependent loops:
    13  1. Node that registers itself as a topic provider will periodically send topics
    14  to the peers.
    15  2. Second loop advertises itself to peers in the network.
    16  It does so by requesting peers from known peers and sending ping request to them.
    17  As a result all peers in the network will learn about new node faster.
    18  
    19  Search
    20  ------
    21  ![alt text](artifacts/v5search.png)
    22  
    23  Search request spawns single loop for every searched topic. This loop
    24  request peers from known peers (starting from one-self) and then requests
    25  from them nodes that are registered as a topic provider.
    26  
    27  We can control how often this loop wil run, more about it in the next section.
    28  
    29  Peer pool in status-go
    30  ----------------------
    31  
    32  Peer pool uses search mechanism described above to find peers in a timely manner
    33  without using a lot of resources in the long run. It achieves it by introducing
    34  two modes of synchronization:
    35  
    36  1. Fast mode.
    37  
    38  Peer will run search loop quite often (every 500ms at the time of writing) with the
    39  goal to visit as much nodes as possible and once it will find minimum amount of
    40  peers with required capability it will swich to slow mode.
    41  
    42  1. Slow mode.
    43  
    44  This mode might be useful to get information about new peers that can be used
    45  later if initial set of peers disappears. Should run once in a 10m-30m.
    46  
    47  However finding peers even with fast mode can take noticeable amount of time,
    48  which is fine if node is a long-running, but will be a huge problem on a mobile
    49  device. To workaround such problem we will introduce a leveldb cache that will
    50  maintain a list of peers that was used by a device before it went offline.
    51  
    52  Another important detail of a peer pool is a support of min and max amount of peers:
    53  
    54  - min is required to switch from fast to slow sync mode
    55  - max is an upper limit that can be used by a single node