Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move length-determining fields to the start of STREAM and ACK #277

Merged
merged 1 commit into from Feb 16, 2017

Conversation

martinthomson
Copy link
Member

I considered a more violent change here, but decided to start with the simplest move.

I really want to rewrite the ACK section, it's a little obtuse as it is. I think that it could be made a lot clearer.

Closes #62.

Copy link
Contributor

@ianswett ianswett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's do this for now, we can go through and simplify other things later.

@@ -920,28 +920,29 @@ A STREAM frame is shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Data Length (16)] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (8/16/24/32) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset (0/16/24/32/40/48/56/64) ...
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, we have 8 different offsets. And they 're not even evenly spaced. That's cute.

Jana and I can clean that up in our draft, though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's a separate issue. I can understand why it is that way. That is, there isn't much value in an 8-bit offset given that you are likely to cram > 8 octets in a single packet, which is the most common case for needing offsets. That said, I think that we would want to discuss what options make sense.

I can see arguments for 0, 16, and 32 and 64 would avoid the need for rollover calculations. The other options seem like overoptimizing. varint encoding would be preferable in that case.

@janaiyengar janaiyengar merged commit 5cf69e8 into master Feb 16, 2017
@MikeBishop MikeBishop deleted the move_frame_lengths branch March 10, 2017 18:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants