You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: