-
Notifications
You must be signed in to change notification settings - Fork 24
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
feat: add before handle #158
Conversation
@zhangsoledad is assigned as the chief reviewer |
@@ -140,6 +142,8 @@ pub struct MetaBuilder { | |||
service_handle: ProtocolHandle<Box<dyn ServiceProtocol + Send + 'static>>, | |||
session_handle: SessionHandleFn, | |||
select_version: SelectVersionFn, | |||
before_send: Option<Box<dyn Fn(bytes::Bytes) -> bytes::Bytes + Send + 'static>>, |
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.
What's the choice here that before_send
is an Option
, but before_receive
is a Box<Fn>
?
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.
Because the message has a unified entry, only one fn can be used.
The received is that each protocol in each session has an entry and there is no aggregation, so here need to have a handler that can always generate the exact same function, fn -> Option<fn>
.
Each time a protocol open, get a receive fn
to it's stream
7743992
to
ba300b2
Compare
ba300b2
to
2cc02ef
Compare
Currently, all the handles on the framework are after handles. If you want to use the before operation on the upper layer, it will be very tricky and difficult to maintain.
Just like you want to add a compressed feature to some of the upper layers of the protocol. The current way of coding can only be as shown in nervosnetwork/ckb#859.
The p2p framework is very different from the web framework in that there is a need for broadcasting. If the function of compressing messages is done in the codec, it will waste a lot of CPU time, because the same message will increase the compression time as the number of connections grows.
We need a unified way of handling broadcast messages, not exactly the same as codec, just like global preprocessing. This pr adds two preprocessing methods for each protocol, which makes it easier to preprocess messages.
Good luck to you