Skip to content

Conversation

ElFantasma
Copy link
Contributor

@ElFantasma ElFantasma commented Oct 7, 2025

Motivation
Currently our Peer Connections can handle only one request at a time. We want to be able to handle multiple requests and be able to redirect their responses to proper actors.

Description
Improve request/response handling on peer connections:

Done:

  • Rename structs and functions to improve readability
  • Make internal PeerConnection structs and enums private exposing only necessary api
  • Have an internal request hashmap to direct expected responses to correct channels
  • Removed receiver channel lock() from PeerHandler code and replaced by a oneshot channel
  • Removed PeerChannels
  • Move timeout and response handling on PeerConnection side.
  • Remove all mark_in_use and free logic that won't be required.

To do:

  • Implement a load balancer algorithm measure performance and use PeerConnection in a balanced fashion

Closes #3963

@github-actions github-actions bot added the L1 Ethereum client label Oct 7, 2025
Copy link

github-actions bot commented Oct 7, 2025

Lines of code report

Total lines added: 260
Total lines removed: 227
Total lines changed: 487

Detailed view
+-----------------------------------------------------------+-------+------+
| File                                                      | Lines | Diff |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/discv4/peer_table.rs         | 914   | -78  |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/metrics.rs                   | 582   | +18  |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/network.rs                   | 355   | -3   |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/peer_handler.rs              | 1751  | -49  |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/rlpx/connection/codec.rs     | 318   | +28  |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/rlpx/connection/handshake.rs | 526   | +20  |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/rlpx/connection/server.rs    | 970   | +108 |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/rlpx/error.rs                | 115   | +15  |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/rlpx/eth/backend.rs          | 97    | +5   |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/rlpx/eth/eth68/status.rs     | 115   | +3   |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/rlpx/eth/eth69/status.rs     | 115   | +3   |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/rlpx/eth/update.rs           | 68    | +3   |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/rlpx/initiator.rs            | 97    | +2   |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/rlpx/l2/l2_connection.rs     | 447   | +16  |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/rlpx/l2/messages.rs          | 165   | +3   |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/rlpx/message.rs              | 326   | +31  |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/sync.rs                      | 1476  | -11  |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/sync/state_healing.rs        | 369   | +2   |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/sync/storage_healing.rs      | 563   | +1   |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/tx_broadcaster.rs            | 305   | -4   |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/types.rs                     | 498   | +2   |
+-----------------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/utils.rs                     | 180   | -82  |
+-----------------------------------------------------------+-------+------+

@ElFantasma ElFantasma marked this pull request as ready for review October 9, 2025 16:03
@ElFantasma ElFantasma requested a review from a team as a code owner October 9, 2025 16:03
@ethrex-project-sync ethrex-project-sync bot moved this to In Review in ethrex_l1 Oct 9, 2025
) -> Result<Message, PeerConnectionError> {
let id = message
.request_id()
.expect("Cannot wait on request without id");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we really want to panic here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sending a request (to expect a response) using a message that does not have request id is a bug... (the task will wait a response that will never come)
I'd prefer a compile error here, to prevent the dev to introduce the bug, but since we can't with our current types, lets panic

Message::AccountRange(message) => Some(message.id),
Message::StorageRanges(message) => Some(message.id),
Message::ByteCodes(message) => Some(message.id),
Message::TrieNodes(message) => Some(message.id),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: cant you use | like you do below?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How's that? message on each matching clause has a different type 🤔

Comment on lines +169 to 175
/// Increment the number of ongoing requests for this peer
pub async fn inc_requests(&mut self, node_id: H256) -> Result<(), PeerTableError> {
self.handle
.cast(CastMessage::IncRequests { node_id })
.await?;
Ok(())
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be managed by peer itself?

rlpx::{Message, connection::server::CastMessage, snap::TrieNodes},
};
#[cfg(feature = "rocksdb")]
use tracing::error;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this gated with rocksdb?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

L1 Ethereum client

Projects

Status: In Review

Development

Successfully merging this pull request may close these issues.

Add a table for backend RLPxConnection

3 participants