-
Notifications
You must be signed in to change notification settings - Fork 60
feat(l1): add rpc endpoint admin_peers #2732
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Lines of code reportTotal lines added: Detailed view
|
@@ -170,6 +173,7 @@ pub async fn start_api( | |||
active_filters: active_filters.clone(), | |||
syncer: Arc::new(syncer), | |||
client_version, | |||
peer_handler, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we refactor this to group a bunch of p2p related concepts like local_p2p_node
, local_node_record
, peer_handler
, maybe syncer
into something like Node
or similar? Maybe out of scope of this PR, but RpcApiContext
is like a bag were we just throw random things, would be nice to be a bit more thoughtful in this regard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think syncer and peer handler should remain separate from the rest as they have their own api and are not used in conjunction. I think readable data such as jwt_secret and local node data could be grouped together
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ill do this in a separate PR to be cleaner
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR opened #2752
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the PR has been merged, the peer handler should be in the Node now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NodeData
contains static data about our node, while the PeerHandler actually has its own behaviour and has nothing to do with the data stored in NodeData
, that's why Id rather keep them separate
**Motivation** `RpcContext` has become quite extensive lately, so we need to group some of its fields into individual structures that hold data used for similar purposes. This PR groups static data related to the node (such as p2p address, version, etc) into a `NodeData` struct in order to simplify it. **Description** * Group static data about the node held in `RpcContext` into `NodeData` * (Misc) Remove duplicated code between test functions <!-- A clear and concise general description of the changes this PR introduces --> <!-- Link to issues: Resolves #111, Resolves #222 --> Addresses review comment: #2732 (comment)
**Motivation** `RpcContext` has become quite extensive lately, so we need to group some of its fields into individual structures that hold data used for similar purposes. This PR groups static data related to the node (such as p2p address, version, etc) into a `NodeData` struct in order to simplify it. **Description** * Group static data about the node held in `RpcContext` into `NodeData` * (Misc) Remove duplicated code between test functions <!-- A clear and concise general description of the changes this PR introduces --> <!-- Link to issues: Resolves #111, Resolves #222 --> Addresses review comment: #2732 (comment)
Benchmark for fd726ecClick to view benchmark
|
Benchmark for 7d331aaClick to view benchmark
|
Benchmark for e70f8b2Click to view benchmark
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should integrate the peer table into the Node. Rest looks good
@@ -170,6 +173,7 @@ pub async fn start_api( | |||
active_filters: active_filters.clone(), | |||
syncer: Arc::new(syncer), | |||
client_version, | |||
peer_handler, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the PR has been merged, the peer handler should be in the Node now
) { | ||
let peer = self.get_by_node_id_mut(node_id); | ||
if let Some(peer) = peer { | ||
peer.channels = Some(channels); | ||
peer.supported_capabilities = capabilities; | ||
peer.is_connected = true; | ||
peer.is_connection_inbound = inbound; | ||
} else { | ||
debug!( | ||
"[PEERS] Peer with node_id {:?} not found in the kademlia table when trying to init backend communication", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the debug information also include if it's inbound?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a very edge case rather than something we want to actively look for
|
||
/// Creates a dummy PeerHandler for tests where interacting with peers is not needed | ||
/// This should only be used in tests as it won't be able to interact with the node's connected peers | ||
pub fn dummy() -> PeerHandler { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: keep this inside test flag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to but the test
feature doesn't behave well when importing across crates
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…to rpc-admin-peers
Benchmark for 700f068Click to view benchmark
|
Motivation
Support rpc endpoint
admin_peers
Description
admin_peers
peer_handler: PeerHandler
field toRpcContext
so we can access peers from the rpcSyncer
&SyncManager
now receive aPeerHandler
upon creation instead of aKademliaTable
Data missing compared to geth implementation:
Closes #2671