[Update] Week #5 - gossip, peer pool

This is an update on what I’ve been working on since the last update.

Ping message check

Related PR: PR #3090

The PR was merged finally. It enforces the max number of peers in ping message to be 32.

Peer propagation

Related PR: PR #3123, PR #453 (protocol)

The node used to gossip random peers from both verified and unverified pool. Since we have issue with too many dead peers present in the unverified pool, these peers were propagated, too. The PR changes behaviour of the peer pool so the random peers are now selected only from the verified pool. This means that only peers that the node is able to connect to are propagated (so no more dead peers in ping message).

Periodic check of unverified peers

Related PR: PR #3135

When the node tries to establish a connection it selects an available peer from the verified pool first, if there is no available peer, it selects a random peer from the unverified pool (most likely dead one). In order to increase the likelihood that the node is able to establish a connection, there is now a mechanism that periodically selects a random peer from the unverified pool and tries to connect to it (just TCP) to find out if it’s alive. If the peer is alive, it’s moved to the verified pool, so the node will have some available peer in the verified pool.

Default max_update_lapse

Related PRs: PR #3138, PR #3117

max_update_lapse is used for checking if peers are considered old and should be removed (this check is performed when a peer pool is reasonably full and there are new peers added to it, PR #3117 makes these checks more frequent). Its default value is 30 days which is too long and should be decreased to just couple of hours.

3 Likes