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.

Sign up for GitHub

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

Jump to bottom

Fixup implicit stream opening #1549

Merged
merged 4 commits into from Jul 12, 2018
Merged

Fixup implicit stream opening #1549

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
8b51ff5
Fixup implicit stream opening
martinthomson Jul 11, 2018
4fd3dc2
For Ian
martinthomson Jul 11, 2018
595c9dd
More tweaking
martinthomson Jul 12, 2018
da2ea39
Plural
martinthomson Jul 12, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
9 changes: 4 additions & 5 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -3970,11 +3970,10 @@ Receiving a MAX_STREAM_DATA frame implies that the remote peer has opened the
stream and is providing flow control credit. A MAX_STREAM_DATA frame might
arrive before a STREAM or STREAM_BLOCKED frame if packets are lost or reordered.

In addition to the exchange of frames related to the stream, a stream is created
before any higher-numbered stream of the same type can be created. That is,
receipt of a frame that would open a stream causes all lower-numbered streams of
the same type to be opened first. This ensures that the creation order for
streams is consistent on both endpoints.
Before creating a stream, all lower-numbered stream of the same type MUST be
Copy link
Contributor

Choose a reason for hiding this comment

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

streams

created. That means that receipt of a frame that would open a stream causes all
lower-numbered streams of the same type to be opened in numeric order. This
ensures that the creation order for streams is consistent on both endpoints.

In the "Recv" state, the endpoint receives STREAM and STREAM_BLOCKED frames.
Incoming data is buffered and can be reassembled into the correct order for
Expand Down