P2p: count connections without activity; use the counter when calculating next connection attempt time, to make it progressively bigger as the counter grows.#2026
Open
ImplOfAnImpl wants to merge 3 commits intop2p_pass_rng_to_peer_managerfrom
Conversation
…lculating `next_connect_time` the same way `fail_count` has been used.
…ce instead of sending `TransactionSyncMessageTag`/`BlockSyncMessageTag` on each sync message. Add a test to check that the message is actually sent. Some renaming.
1ceaf37 to
5666d88
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If an outgoing connection gets closed without peer having done any activity (which means it didn't sent us any message except for
WillDisconnect), peer address'sconnections_without_activity_countwill be incremented. This counter is then used inAddressData::next_connect_timethe same way as the already existingfail_countis - the bigger the counter, the longer the time before the next connection is attempted.I.e. if the node gets banned by a peer (which doesn't necessarily mean that there is something wrong with the node, e.g. the fork detection script uses banning to prevent connecting to the same nodes every time), the current behavior is that the node will relentlessly try connecting to the peer every 10 seconds or so. The new behavior is that the delay before the next connection attempt will gradually increase as the counter grows, up to the maximum (which is currently 1h for non-
reserved peers).
Note:
fail_count,connections_without_activity_countwon't cause the peer address to becomeUnreachableeventually.fail_count,connections_without_activity_countis not stored in the peer db on disk; it only exists in memory and will be zero again when the node is restarted.