Remove multistream-select extra roundtrip #2983
Comments
mergify bot
added a commit
that referenced
this issue
Nov 11, 2022
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. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This was referenced Feb 9, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The smoldot multistream-select implementation doesn't support assuming that the remote supports the requested protocol. This means an extra round-trip every time a protocol is negotiated.
The text was updated successfully, but these errors were encountered: