In libp2p-request-responses, give the possiblity to specify a limit to the number of simultaneous requests per peer

[tomaka]

Considering that there doesn't exist any back-pressure mechanism when it comes to opening substreams, we need way to protect against an attacker opening thousands of substreams on a connection.

While the multiplexer does enforce a limit to the total number of open substreams per connection, this value must be pretty high in order to avoid accidentally reaching it in legitimate scenarios.

Instead, it seems preferable to me to enforce, for each individual peer and protocol, the number of substreams that can be open simultaneously.

When it comes to request-response protocols, this can be done by enforcing a limit to the number of simultaneous requests that a remote is capable of making.
I'm opening this issue in libp2p because to me it is preferable to do this verification in the ProtocolsHandler.

[tomaka]

I'm unsure whether we should check against this limit on the sending side too, or if we delegate this responsibility to the user.
Delegating this responsibility to the user makes this potentially very error-prone.

[twittner]

As mentioned elsewhere I think it would be a good idea to send metadata such as error codes or back-pressure information together with the actual payload. Presumably the limit depends on the capacity of a node and is thus quite dynamic.

[romanb]

Closed by #1726, #1731. For bugs, new tweaks or other change requests relating to this functionality, it is probably better to open new issues.