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

Streams start as "idle" #778

Closed
ekr opened this issue Sep 18, 2017 · 2 comments
Closed

Streams start as "idle" #778

ekr opened this issue Sep 18, 2017 · 2 comments
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.

Comments

@ekr
Copy link
Collaborator

ekr commented Sep 18, 2017

There are two ways of thinking about streams:

  1. All 2^32 streams exist but are in the IDLE state and transition to other states when messages are received/sent on them.
  2. Streams are created when the aforementioned messages are received/sent.

The document is kind of agnostic on this, talking about them as being in IDLE (the state machine) but also talking about streams being created:

   A QUIC endpoint cannot reuse a Stream ID.  Streams MUST be created in
   sequential order.  Open streams can be used in any order.  Streams

I tend to think that it would be better to talk about streams being created and remove the IDLE state, but in any case it would be good if the draft were consistent.

@ianswett
Copy link
Contributor

Streams being created better matches the way they're managed in data structures, so I would tend to favor that as well.

@mnot mnot added -transport editorial An issue that does not affect the design of the protocol; does not require consensus. labels Sep 25, 2017
@martinthomson
Copy link
Member

The new stream states don't exist until they transition to an active state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
None yet
Development

No branches or pull requests

4 participants