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

Change StreamID to Stream ID #431

Merged
merged 2 commits into from
Apr 13, 2017
Merged

Change StreamID to Stream ID #431

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
10294e3
changes StreamID to Stream ID
kmindi Apr 5, 2017
44b53c0
changes StreamID to Stream ID
kmindi Apr 5, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions draft-ietf-quic-http.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -141,7 +141,7 @@ While connection-level options pertaining to the core QUIC protocol are set in
the initial crypto handshake, HTTP-specific settings are conveyed
in the SETTINGS frame. After the QUIC connection is established, a SETTINGS
frame ({{frame-settings}}) MUST be sent as the initial frame of the HTTP control
stream (StreamID 3, see {{stream-mapping}}). The server MUST NOT send data on
stream (Stream ID 3, see {{stream-mapping}}). The server MUST NOT send data on
any other stream until the client's SETTINGS frame has been received.

## Draft Version Identification
Expand Down Expand Up @@ -359,7 +359,7 @@ pushes via the SETTINGS_DISABLE_PUSH setting in the SETTINGS frame (see
{{connection-establishment}}), which defaults to 1 (true).

As with server push for HTTP/2, the server initiates a server push by sending a
PUSH_PROMISE frame containing the StreamID of the stream to be pushed, as well
PUSH_PROMISE frame containing the Stream ID of the stream to be pushed, as well
as request header fields attributed to the request. The PUSH_PROMISE frame is
sent on the control stream of the associated (client-initiated) request, while
the Promised Stream ID field specifies the Stream ID of the control stream for
Expand Down
18 changes: 9 additions & 9 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2185,18 +2185,18 @@ permitted in the description of a state as a connection error
## Stream Identifiers {#stream-identifiers}

Streams are identified by an unsigned 32-bit integer, referred to as the
StreamID. To avoid StreamID collision, clients MUST initiate streams usinge
odd-numbered StreamIDs; streams initiated by the server MUST use even-numbered
StreamIDs.
Stream ID. To avoid Stream ID collision, clients MUST initiate streams usinge
odd-numbered Stream IDs; streams initiated by the server MUST use even-numbered
Stream IDs.

A StreamID of zero (0x0) is reserved and used for connection-level flow control
frames ({{flow-control}}); the StreamID of zero cannot be used to establish a
A Stream ID of zero (0x0) is reserved and used for connection-level flow control
frames ({{flow-control}}); the Stream ID of zero cannot be used to establish a
new stream.

StreamID 1 (0x1) is reserved for the cryptographic handshake. StreamID 1 MUST
Stream ID 1 (0x1) is reserved for the cryptographic handshake. Stream ID 1 MUST
NOT be used for application data, and MUST be the first client-initiated stream.

A QUIC endpoint cannot reuse a StreamID on a given connection. Streams MUST be
A QUIC endpoint cannot reuse a Stream ID 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 in the same
direction being counted as open.
Expand Down Expand Up @@ -2343,7 +2343,7 @@ expected to be sent infrequently in common cases, but they are considered useful
for debugging and monitoring purposes.

A receiver advertises credit for a stream by sending a WINDOW_UPDATE frame with
the StreamID set appropriately. A receiver may use the current offset of data
the Stream ID set appropriately. A receiver may use the current offset of data
consumed to determine the flow control offset to be advertised.
A receiver MAY send copies of a WINDOW_UPDATE frame in multiple packets in order
to make sure that the sender receives it before running out of flow control
Expand All @@ -2352,7 +2352,7 @@ credit, even if one of the packets is lost.
Connection flow control is a limit to the total bytes of stream data sent in
STREAM frames on all streams contributing to connection flow control. A
receiver advertises credit for a connection by sending a WINDOW_UPDATE frame
with the StreamID set to zero (0x00). A receiver maintains a cumulative sum of
with the Stream ID set to zero (0x00). A receiver maintains a cumulative sum of
bytes received on all streams contributing to connection-level flow control, to
check for flow control violations. A receiver may maintain a cumulative sum of
bytes consumed on all contributing streams to determine the connection-level
Expand Down