Limited of numbers of streams?
svanharmelen opened this issue · 8 comments
If I read and understand this code correctly, it seems to me that it imposes a hard limit here.
So what are the options if you would like to use Yamux in a long running process that could use more than math.MaxUint32-1 streams? Most likely not all at the same time of course, but as the preferred way to manage stream ID's seem to be to increment the ID with 1 you will hit the limit sooner or later.
So could this logic be updated/changed without breaking existing stuff? And/or are there other ways to (safely) be able to reuse old ID's of streams that aren't used anymore?
The logic can certainly be changed. I think the only requirement is that the steam is not in use. So technically we could wrap around back to one (zero is reserved) and scan for the next free ID. I just haven't had a use case yet for billions of streams ;)
Notes:
- this would be a further departure from SPDY: https://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3#TOC-2.3.2-Stream-creation (i dont even know how they didn't address this...)
- it seems this even made it past http2 review - https://http2.github.io/http2-spec/#StreamIdentifiers
- do we know why they did this? they must've had a good reason for this... fast allocation of new streams? (int incr, not map lookup).
- it is also possible that there's complicated state problems if a streamID reuse is attempted and the other side hasn't torn down the stream fully. (not sure whether this has any bearing on yamux)
this is sad. wonder if there are other mines in the "using spdy/http2 as a general stream muxer"
@jbenet Thanks for the notes. I agree there is probably a good reason. One thing I can imagine is the "sparse array" issue. There will undoubtably be some stream IDs still in use, whereas atomically incrementing we guarantee they aren't in use to the max int point.
Departing from SPDY would be fine, yamux is already pretty far gone from it. We used SPDY (as well as some other prior attempts at this) as reference material, but made no real intention to follow it.
after a bit of reading on it, I really dont think that http2 is a good canidate for use as a general stream muxer.
@mitchellh ok that all sounds good.
btw, if you're interested, we (ipfsers) seek to pick (or make) a simple spdy/http2/quic inspired stream muxer that is simple to implement across languages. we've used yamux with good success so far (shipped in the IPFS alpha), but were exploring spdy/http2 since those will get implementations in other languages faster. Another option is to pick yamux or muxado2 and bite the bullet and write the common denominator impls (go, js, and c). (@mitchellh have you had to use yamux in js yet?)
@jbenet I haven't, but we tried really hard to get http2 to work prior to building Yamux. The main issue we ran into (apologize if this information is incorrect or outdated since it was years ago) was that the semantics of HTTP were too closely tied to the multiplexing. The multiplexing had control messages for things like headers and so on piggybacking onto stream messages and it was hard to separate that.
makes sense, thanks for the info.
As this is a super old issue that never caused me any issues IRL, I'm going to close this one. Thanks!