You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This may lead to peers keeping connections alive due to state mismatch.
My understanding of the libp2p spec is that the multistream header should be send once, as the first message. Then, peers should negotiate the protocol names they want to serve.
The listener code is correctly awaiting the header once:
This PR ensures that the `/multistream/1.0.0` header can only be
received once during a protocol negotiation.
This is fixed for both the V1 and V1Lazy variations.
While at it, have added a few tests to check:
- protocol negotiation
- protocol negotiation failure due to unsupported protocols
- lazy protocol negotiation awaits protocol message before closing (to
be fixed by: #60)
- low level protocol listener that writes the expected messages
- low level protocol listener that submits multiple headers, both for V1
and V1 lazy
Closes: #59
cc @paritytech/networking
---------
Signed-off-by: Alexandru Vasile <[email protected]>
The dialer of the multistream protocol can accept multiple times the
multistream
V1 header:litep2p/src/multistream_select/dialer_select.rs
Lines 195 to 197 in cc043b6
This may lead to peers keeping connections alive due to state mismatch.
My understanding of the libp2p spec is that the multistream header should be send once, as the first message. Then, peers should negotiate the protocol names they want to serve.
The listener code is correctly awaiting the header once:
litep2p/src/multistream_select/listener_select.rs
Line 149 in cc043b6
The issue is also present in the rust-libp2p repo, which is where I suspect our code took inspiration from.
Let's return
ProtocolError::InvalidMessage
if the header is sent multiple times.cc @paritytech/networking
The text was updated successfully, but these errors were encountered: