Re: Identify streams unidirectional vs bidirectional based on stream ID

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Especially with the new variable length encoding proposal, storing the
identifiers early makes sense, as you only have to inspect the first byte.
But it gets complicated, because you don’t want to use 8 bytes for some
stream types and you don’t want the bits at some random location in a
decoded 8 byte representation either.

Regardless of bit placement, encoding state using bits is not ideal when
considering variable length encoding because you now use two bits for
length and two bits for stream type, leaving only 16 different streams
before the stream identifier needs to use two bytes, and so forth.


Kind Regards,
Mikkel Fahnøe Jørgensen


On 13 October 2017 at 21.50.06, Hugues Fafard ([e-mail]) wrote:

I see, you used the 2 least significant bits to encode that
information. When only using one bit to indicate the direction, it
boiled down to odd/even which more or less made sense, but when using
2 bits that breaks apart.

Why not use the most significant bits instead? That way, getting the
'clean' stream ID without the flags would be as simple doing a `&
0x3F...FF` instead of bit-shifting things around. Similarly, encoding
the stream ID would just entail `| 0x?0...00` to set the appropriate
bits and also avoid bit-shifts.

Regards,
Hugues

On 2017-10-13 20:51, Ryan Hamilton wrote:
> As I understand the discussions at the interim, we've decided to
> allow streams to be unidirectional or bidirectional. I support this
> idea and was motivated to write up an idea I've been thinking about
> for a while. In the same way that we use a bit in the stream ID to
> identify the client vs server nature of the stream, we can use a
> bit to identify the directionality. This divides the stream ID
> space neatly into 4 distinct spaces (much like the 2 two we have
> today: client/server). In addition this means that a stream ID
> always uniquely identifies a single stream, and frames which
> mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA,
> RST_STREAM, etc) do not need to explicitly convey the
> directionality as fields in those frames (or implicitly based on
> the directionality of the frames themselves).
>
> https://github.com/quicwg/base-drafts/pull/872
>
> Cheers,
>
> Ryan