-
Notifications
You must be signed in to change notification settings - Fork 108
refactor(l1): multiplex p2p requests #4797
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
|
) -> Result<Message, PeerConnectionError> { | ||
let id = message | ||
.request_id() | ||
.expect("Cannot wait on request without id"); |
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.
do we really want to panic here?
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.
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), |
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: cant you use |
like you do below?
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.
How's that? message
on each matching clause has a different type 🤔
/// 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(()) | ||
} |
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.
Shouldn't this be managed by peer itself?
rlpx::{Message, connection::server::CastMessage, snap::TrieNodes}, | ||
}; | ||
#[cfg(feature = "rocksdb")] | ||
use tracing::error; |
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.
Why is this gated with rocksdb
?
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:
PeerConnection
structs and enums private exposing only necessary apilock()
fromPeerHandler
code and replaced by a oneshot channelPeerConnection
side.mark_in_use
andfree
logic that won't be required.To do:
PeerConnection
in a balanced fashionCloses #3963