Well, that's half of the downside presented, the other half is that it's split be server/client connections. I assume this was done because it simplifies the tracking of the next stream identifier, because you can just keep a counter and increment, rather than a table of used streams to check a new random identifier against?
Comments
It was not ignored, it was very much made on purpose because of a certain popular programming language not having unsigned 32 bit variables...
Well, that's half of the downside presented, the other half is that it's split be server/client connections. I assume this was done because it simplifies the tracking of the next stream identifier, because you can just keep a counter and increment, rather than a table of used streams to check a new random identifier against?
Correct, something that was used already in SPDY and proved to be very handy and convenient so it was kept in HTTP/2.
BTW, recent data shows that Firefox does (on median) about 8 requests per HTTP/2 connection, up from slightly more than 1 on HTTP/1.1
So, if we ever close a connection from having reached a billion streams we are in a very very good position.
Doubling the number of them doesn't make it more right.
Are you talking about Java?