-
Notifications
You must be signed in to change notification settings - Fork 131
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
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 🤔
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.
you are right @ElFantasma
| /// 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?
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.
The number of requests is used for the math to balance the load between all peers, when choosing one peer to use. If this number was on peer's processes, it would mean that the get_best_peer function would have to message every active peer before selecting one.
| 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?
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.
To be honest: I don't know. It came from a merge from main commit, but it is not in the original commit 🤷♂️
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.
Fixed, if removed it was warning on:
--> crates/networking/p2p/utils.rs:9:5
|
9 | use tracing::error;
| ^^^^^^^^^^^^^^
|
= note: `-D unused-imports` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unused_imports)]`
But lucky for me there was an unguarded use of tracing::error!
pablodeymo
left a comment
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.
🚀
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:
PeerConnectionstructs and enums private exposing only necessary apilock()fromPeerHandlercode and replaced by a oneshot channelPeerConnectionside.mark_in_useandfreelogic that won't be required.To do:
PeerConnectionin a balanced fashionCloses #3963