-
Notifications
You must be signed in to change notification settings - Fork 2
P2P network peer domain
The peers package holds classes responsible for bootstrapping the network and maintaining a healthy network of neighbor peers.
Coordinating different specialized managers for bootstrapping into the network and maintaining a healthy group of neighbor peers.
It starts by bootstrapping the network of neighbor peers using the PeerExchange which provides information of other available peers in the network. After the initial network of mostly outbound connections has been created we switch strategy to maintain a preferred composition of peers managed in PeerGroupHealth.
Responsible for the PeerExchange protocol.
Provides the peers to connect to for peer exchange as well the peer to send to the peer and accepts the received peers from the exchange protocol.
Responsible for maintaining a healthy composition of peers after the initial network setup.
A shared model holding the peers in different categories and self-manages connected peers using the ConnectionListener
Holds configuration properties like target number of connections
Encapsulate peer node with meta data useful for our context.
We have 4 categories of peers:
- Seed nodes (provided to application as hard coded list or application configuration, using PeerExchangeSelection)
- Persisted peers (persisted from previous sessions, selected by PeerExchangeSelection)
- Reported peers (connected and reported peers delivered from other peers, using PeerExchangeSelection)
- Connected peers (current live connections)
At the bootstrapPeerExchange method we delegate the boostrap to PeerExchange and once we get the result we check if we have sufficient connections and sufficient reported peers. If not we run the peer exchange protocol on PeerExchange again after a delay. In any case we complete the future once PeerExchange completes. In case of starting the network it is expeted that the first peer has no other connections and no reported peers. With the repeated delay it has a chance to discover other peers over time.
At the bootstrap method we request the peer addresses to be used for the exchange protocol from the PeerExchangeSelection. PeerExchangeSelection maintains a hashset of alreeady used peers to avoid that we use the same peers in repeated requests. The PeerExchangeSelection uses the following stategy for selecting the list of peers (numbers are default numbers from config):
- Add 2 seednodes to a list. Ignore myself if I am a seed node. Ignore already used nodes.
- Add 8 persisted peers. Ignore already used nodes.
- Add 4 reported peers. Ignore already used nodes.
- Add all connected peers. Ignore already used nodes. Ignore seed nodes.
- If we have already connectons (repeated case) we check how many connections we miss to reach our target (8)
- We use that number of missing connections to limit our merged list.
- The list is ordered as noted above which represents priorities, so if we truncate we remove lower priorities first.
We use that provided list for executing the peer exchange request/response protocols with the peers. The selection of the peers we report to our peer is done in PeerExchangeSelection as well.
- Get all reported peers from PeerGroup
- Sort it by creation date
- Truncate the list to 100 items
- Add our connected peers. We use a hashset to avoid duplicates. Ignore seed nodes.
Once we receive the response we add the reported peers using the PeerExchangeSelection as well. We apply filtering to remove our own address and add the peers to reported peers in PeerGroup.
TBD