Limited of numbers of streams? about yamux HOT 8 CLOSED

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 ;)

from yamux.

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"

from yamux.

@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.

from yamux.

after a bit of reading on it, I really dont think that http2 is a good canidate for use as a general stream muxer.

from yamux.

@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?)

from yamux.

@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.

from yamux.

makes sense, thanks for the info.

from yamux.

As this is a super old issue that never caused me any issues IRL, I'm going to close this one. Thanks!

from yamux.