Re:gRPC: Internet-scale RPC framework is now 1.0
by bagder on Tuesday August 23, 2016 @02:07PM
(#12345951)
It was not ignored, it was very much made on purpose because of a certain popular programming language not having unsigned 32 bit variables...
Re:gRPC: Internet-scale RPC framework is now 1.0
by kbenson on Tuesday August 23, 2016 @02:12PM
(#12346007)
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?
Re:gRPC: Internet-scale RPC framework is now 1.0
by bagder on Tuesday August 23, 2016 @02:15PM
(#12346039)
Correct, something that was used already in SPDY and proved to be very handy and convenient so it was kept in HTTP/2.
Re:gRPC: Internet-scale RPC framework is now 1.0
by bagder on Tuesday August 23, 2016 @02:18PM
(#12346061)
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.
Re:gRPC: Internet-scale RPC framework is now 1.0
by spullara on Tuesday August 23, 2016 @02:40PM
(#12346292)
Doubling the number of them doesn't make it more right.
Re:gRPC: Internet-scale RPC framework is now 1.0
by vamega on Tuesday August 23, 2016 @04:06PM
(#12347081)
Are you talking about Java?
Re:gRPC: Internet-scale RPC framework is now 1.0
by kbenson on Tuesday August 23, 2016 @02:08PM
(#12345956)
So, that's the other side of the argument? I assume there was at least a reason they specced it this way originally, even if under comparison those reasons wouldn't have held up. Was there any justification, or was it literally ignored?
Re:gRPC: Internet-scale RPC framework is now 1.0
by niftich on Tuesday August 23, 2016 @03:27PM
(#12346722)
It was considered a non-issue, since it's easy to work around. See https://github.com/http2/http2-spec/issues/61
Since HTTP2 is a client->server protocol, the server can close whenever and the client can just open another one.
Re:gRPC: Internet-scale RPC framework is now 1.0
by iamgopal on Tuesday August 23, 2016 @02:05PM
(#12345933)
May be I'm stupid, but how hard it is it to reimplement it as 64 bit unsigned ?
Re:gRPC: Internet-scale RPC framework is now 1.0
by placeybordeaux on Tuesday August 23, 2016 @02:44PM
(#12346337)
It would likely require a new version on the protocol level.
Re:gRPC: Internet-scale RPC framework is now 1.0
by opinali on Tuesday August 23, 2016 @03:12PM
(#12346585)
Support for Javascript? (53-bit mantissa limit)
Re:gRPC: Internet-scale RPC framework is now 1.0
by plywoodtrees on Tuesday August 30, 2016 @05:20PM
(#12394010)
Is the lack of reuse something to do with its evolution from QUIC as a loosely ordered UDP-based protocol?
Hilarious. People called this issue out as an obvious flaw when HTTP/2.0 was first proposed, got ignored, and here the issue is.
For those unfamiliar:
HTTP/2.0 uses an unsigned 31-bit integer to identity individual streams over a connection.
Server-initiated streams must use even identifiers.
Client-initiated streams must use odd identifiers.
Identifiers are not reclaimed once a stream is closed. Once you've initiated (2^31)/2 streams, you've exhausted the identifier pool and there's nothing you can do other than close the connection.
For comparison, SSH channels use a 32-bit arbitrary channel identifier, specified by the initiating party, creating an identifier tuple of (peer, channel). Channel identifiers can be re-used after an existing channel with that identifier is closed.
As a result, SSH doesn't have this problem, or the need to divide the identifier space into even/odd (server/client) channel space.