-
Notifications
You must be signed in to change notification settings - Fork 74
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
Remove some multistream-select round-trips #2984
Conversation
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.
Automatically approving tomaka's pull requests. This auto-approval will be removed once more maintainers are active.
Note that this optimization is implemented in rust-libp2p. It is optional and disabled by default, but in Substrate we enable it. |
twiggy diff reportDifference in .wasm size before and after this pull request.
|
cc #2983
This PR removes some extra networking round-trips caused by multistream-select.
The way multistream-select works is: we tell the remote that we would like to use a specific protocol, and then the remote answers either yes or no. No is only ever returned if the remote doesn't support the protocol at all, which isn't supposed to happen unless we're talking to a buggy node or to a libp2p-compatible-but-not-Substrate node.
Before this PR, we wait for the remote to send back yes or no. After this PR, we don't wait and simply start sending the protocol-specific data immediately after the request for a protocol, and assume that the remote is going to answer yes.
The negotiation is still properly finished afterwards, so if it turns out that the remote answers no, then we'll still get an error locally. The drawback is that, if the remote answers no, the protocol-specific data that we have eagerly sent will be interpreted as being from the multistream-select protocol, which can lead to confusing decoding errors. However, the trade-off is worth it.
I've done this change only for substreams after the connection has been opened. There are two other unnecessary round-trips during the connection opening, but considering that we don't open connections that often they're actually less important. For this reason, I'll leave #2983 open.