Bootstrapper Mode #268
Merged
Bootstrapper Mode #268
Conversation
This file contains 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
Whenever we establish a connection with a new peer, the first thing to do after the handshake is now to ask the peer for its list of peers. This change is motivated by topological robustness in the context of adversaries who deploy sybil or other attacks. In such a context, the connection is not guaranteed to last and so we want to prioritize the information that affects network topology -- blockchain data may be gathered from other nodes.
Benefits clarity.
This commit - adds a CLI argument `bootstrap` that instructs the client to run in bootstrapper mode, which: - kills the connection with the longest-lived peer when the max num peers is reached, such that: - a new incoming connection can always be established. The number of peers is tested against the maximum prior to entering the peer loop. If the maximum is about to be reached, a message is sent to the main loop, instructing it to select a peer and disconnect from it.
Sword-Smith
requested changes
Nov 27, 2024
| @@ -134,10 +134,20 @@ async fn check_if_connection_is_allowed( | |||
| return ConnectionStatus::Refused(ConnectionRefusedReason::IncompatibleVersion); | |||
| } | |||
|
|
|||
| // If this connection touches the maximum number of peer connections, say | |||
| // so with special OK code. | |||
| if cli_arguments.max_num_peers as usize == global_state.net.peer_map.len() + 1 { | |||
There was a problem hiding this comment.
Shouldn't you also check that the node is running as a bootstrapper node here? It seems to me that all nodes will display this "disconnect" behavior.
There was a problem hiding this comment.
- All nodes (bootstrapper or not) run through the highlighted logic.
- The P2P message
ConnectionStatusis only everRefused(..)orAccepted; the valueAcceptedMaxReachedis filtered out on line 260. - Reading the CLI flag should happen on line 279. Will add that momentarily.
| // get all peers | ||
| let all_peers = global_state.net.peer_map.iter(); | ||
|
|
||
| // filter out CLI peers |
There was a problem hiding this comment.
Excellent that you're allowing CLI arguments to preserve peers that will never be disconnected.
Sword-Smith
approved these changes
Nov 27, 2024
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.
We are observing that people would like to participate in the network but can't because the two nodes listed in the README.md refuse connections. They do this because their max number of peers has already been reached.
This PR adds functionality for running a node in "bootstrapper mode", wherein it will drop the longest-lived peer connection whenever the maximum is reached. This mode is activated through a CLI argument. Whenever an incoming connection is established, if this mode is set, and if the max number of peers has been reached, the peer loop will send a
DisconnectFromLongestLivedPeermessage to the main loop. The main loop iterates over all peers, filters out the peers given as CLI arguments, selects the one with the earliest connection established date, and instructs that peer's peer loop to close the connection.