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

Identify streams unidirectional vs bidirectional based on stream ID #872

Merged
merged 6 commits into from Oct 30, 2017
Merged

Identify streams unidirectional vs bidirectional based on stream ID #872

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
820dd81
Identify unidirectional streams by the 2nd bit in the stream ID
RyanTheOptimist Oct 12, 2017
5061a15
Address nits
RyanTheOptimist Oct 13, 2017
a9b13de
invert
RyanTheOptimist Oct 13, 2017
4137259
clarify
RyanTheOptimist Oct 13, 2017
0740371
more
RyanTheOptimist Oct 13, 2017
afabe8a
Remove unnecessary language
RyanTheOptimist Oct 13, 2017
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
3 changes: 2 additions & 1 deletion draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -2630,7 +2630,8 @@ A stream that is in the "half-closed (local)" state MUST NOT be used for sending
on new STREAM frames. Retransmission of data that has already been sent on
STREAM frames is permitted. An endpoint MAY also send MAX_STREAM_DATA and
STOP_SENDING in this state. Unidirectional streams created by the peer are
immediately half-closed (local) to the receiver.
immediately half-closed (local) to the receiver and are subsequently treated
identically to a half-closed bidirectional stream.

An application can decide to abandon a stream in this state. An endpoint can
send RST_STREAM for a stream that was closed with the FIN flag. The final offset
Expand Down