Should we limit request-response to a single protocol?

[dariusc93]

Going over request-response protocol, I began looking closely at its support for multiple protocols, however I could not find any use-case for supporting multiple protocols while being unable to explicitly send a request over a specific protocol itself, unless there is something I am overlooking (which is possible too). In this case, should we limit it to support a single protocol?

[drHuangMHT]

I don't see how request-response handles multiple protocols because codec::Protocol is AsRef<str>, which I don't believe there is any way of switching between different protocols after reading the code. So yeah we can limit it but it only supports one protocol anyway, we may just need to change the documentation.

[drHuangMHT]

It seems that ethereum is using SubstreamProtocol to identify messages(see here) which caused some problem when trying to deprecate {In, Out}bundOpenInfo here in #5858.

[elenaf9]

The ethereum behavior/ protocol is independent of request-response.

[elenaf9]

The support for multiple protocols can be used to support multiple versions of the same protocol.
After a successful upgrade, Codec implementation is provided with the stream, together with the protocol version that we negotiated with the remote. An implementation may chose to send different variations of a request depending on that version, e.g. if certain request fields are only supported by newer versions.

[drHuangMHT]

But that would be problematic when there is a mismatch between the negotiated substream and the messages right? Isn't this what happened with that issue?

[elenaf9]

We thought that that would be an issue, but later figured out that it isn't. The Codec only starts sending a request (message) after the protocol has been negotiated, and it is informed about the resulting protocol version.
As @dariusc93 noted, it is not possible to beforehand set the protocol that should be negotiated for a specific request (which is what the ethereum protocol that you mentioned above is doing).

[drHuangMHT]

now I don't understand both...

[jxs]

as @elenaf9 described, supporting multiple protocols allows for request-response to negotiated those multiple supported ones.
Codec then receives the AsRef<str> one agreed with the Outbound and send it accordingly.
If request-response only accepted one protocol instead of a list this would not be possible.

I'd like to support the requirements of the Ethereum network in request-response but again, I think we should only implement it when required by someone specifically.

[drHuangMHT]

I thought the problem with request-response is that a request with for example /TODO/0.1.0 opens a substream but because of FuturesUnordered a /TODO/0.2.0 gets negotiated first, causing a mismatch between the message sent over the wire and the protocol used for negotiating a substream. Isn't that the problem?

[elenaf9]

a request with for example /TODO/0.1.0 opens a substream

That's not possible. When opening a new substream, the same list of protocols is used for all requests. It's not possible to individually set a protocol for a specific request.