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

Stream Send State Machine is Confusing #2357

Closed
martinduke opened this issue Jan 22, 2019 · 4 comments
Closed

Stream Send State Machine is Confusing #2357

martinduke opened this issue Jan 22, 2019 · 4 comments
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.

Comments

@martinduke
Copy link
Contributor

The send state machine diagram says that if the "Peer Creates Bidirectional Stream" it should transition to READY and then to SEND. The text says ""a bidrectional stream initiated by a peer... enters the 'Ready' state then immediately transitions to the 'Send' state if the receiving part enters the 'Recv' state."

This seems unnecessarily indirect and opaque. I suggest that instead we say that if a host receives STREAM, STREAM_DATA_BLOCKED, RESET_STREAM, MAX_STREAM_DATA, or STOP_SENDING on an unopened, peer-initiated bidirectional stream, it transitions directly to the "Send" state.

If people agree, I'll file a PR.

@martinduke
Copy link
Contributor Author

"or the peer creates a higher-numbered stream"

@martinthomson martinthomson added editorial An issue that does not affect the design of the protocol; does not require consensus. -transport labels Jan 22, 2019
@martinthomson
Copy link
Member

The current structure is deliberate (operating from memory here, there are too many PRs to search through), because it captures all the events through the one entry-point. Don't feel constrained to follow the state machine in your implementation.

@martinduke
Copy link
Contributor Author

Last call for like-minded folks. I'll close this if no one else thinks it is badly presented.

@martinduke
Copy link
Contributor Author

Closing due to lack of interest

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

2 participants