search

libp2p / specs

Technical specifications for the libp2p networking stack
https://libp2p.io
1.58k stars 275 forks source link

Proposal: dynamically limit the number of streams per protocol #520

Open marten-seemann opened 1 year ago

marten-seemann commented 1 year ago

Some of the protocols running on top of libp2p consume streams greedily, opening as many streams as they can get their hands on.

We now have resource managers in all libp2p implementations that prevent this from becoming a DoS attack, however, when the resource manager kicks in, all that the peer learns is that the stream was reset. This can happen for any number of reasons, so it's really hard to programmatically react to stream resets.

Once we have error code (#479) and HTTP (#508) we can be a lot smarter. By using the 429 HTTP status code (and an equivalent that we define as a stream error code), we can tell the peer that it is (temporarily) overloading us with requests, allowing it to take action (e.g. slow down, wait until a few in-flight requests have finished, etc.).

rkuhn commented 1 year ago

While I agree with the impetus, the approach seems implausibly narrow: why add thousands of pages of spec (i.e. HTTP) when a single protocol message would suffice?

marten-seemann commented 1 year ago

Limiting the number of streams per protocol is not the motivating force behind the libp2p+HTTP proposal. See #477 and https://github.com/libp2p/specs/pull/508#issuecomment-1405977821 for some of the use cases we hope to enable by adding HTTP support.

Neither is HTTP support required to make this work, as I've explained above:

By using the 429 HTTP status code (and an equivalent that we define as a stream error code)

I was just pointing out that this proposal works both over classic libp2p streams (once we have error codes) and for libp2p+HTTP, which is a neat property.