Remove stream reservation #280
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
LGTM. |
janaiyengar
reviewed
Feb 23, 2017
| | | ||
| | send data/ | ||
| | recv data/ | ||
| | recv higher stream |
There was a problem hiding this comment.
What does "recv higher stream" mean?
There was a problem hiding this comment.
Just to be a little clearer, this is a shorthand for "receive a STREAM frame on a peer-initiated stream with a higher number, given that this is also a peer-initiated stream".
draft-ietf-quic-transport.md
Outdated
| the reserved stream transitions to "reserved". | ||
| Receiving a STREAM frame on a peer-initiated stream (that is, a packet sent by a | ||
| server on an even-numbered stream or a client packet on an odd-numbered stream) | ||
| also causes all idle streams with lower numbers to become "open". This could |
There was a problem hiding this comment.
This isn't accurate, since it's only odd/even streams that are marked open. How about '... also causes all lower-numbered idle streams in the same direction to become "open".' ?
There was a problem hiding this comment.
Yep, better. This odds and evens thing is a real drag.
draft-ietf-quic-transport.md
Outdated
| connection. | ||
| A QUIC endpoint cannot reuse a StreamID on a given connection. Streams MUST be | ||
| created in sequential order. Open streams can be used in any order. Streams | ||
| that are used out of order result in lower-numbered streams being counted as |
There was a problem hiding this comment.
"lower-numbered streams in the same direction"
|
Updated. |
janaiyengar
approved these changes
Feb 23, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is based on the outcome of the discussion in #174. The observation there is that using stream X implicitly opens stream X-2; since all streams are opened in sequence, it must just be that the packets that mention stream X-2 got delayed or lost somehow.
Once you accept that, it's also reasonable to allow a different order of stream creation (the point at which numbers are allocated) and stream use (when you send packets on a stream). This neatly addresses the issue whereby server push can promise use of streams, but not use them in the order in which they were promised.
There's a catch here, and it's not one that was introduced by this change, if a server promises more streams than the client permits in its concurrent streams limit, the server cannot use streams beyond the limit. I'll open a bug on that.
Closes #182 - that removed only a few of the application actions. This removes all of them.
Closes #174.