obtaining the stream state about quic-go HOT 5 CLOSED

Here's an API proposal:

We add a new method to the SendStream, ReceiveStream and Stream:

type StreamState int

// TODO: define constants for all stream states defined in RFC 9000

type {Send,Receive}Stream interface {
     StateTransition() <-chan StreamState
}

The channel returned here is a buffered channel, with a capacity sufficient to hold all possible state transitions. I haven't done the math yet, but 8 should be sufficient, maybe even smaller.

The nice property of this channel API is that it doesn't matter when the application calls it: For example, the stream might already be closed when it is called. The channel will then contain all state transitions that happened to reach this state.

On the other hand, it requires a Go routine to block on this channel. Maybe it's better to set a callback:

type {Send,Receive}Stream interface {
     OnStateTransition(func(StreamState))
}

This callback would be called multiple times if multiple state transitions had already happened.

from quic-go.

Note that the callback allows us to have multiple layers set a callback. We'd just wrap the existing callback. It's not terribly efficient, but should be fine for a limited number of callbacks. I don't see how this would work with the channel-based API.

from quic-go.

Alternatively, we could consider changing how the QUIC layers reports streams as completed: We could only do that once the STOP_SENDING error (for send streams) or RESET_STREAM error (for receive streams) has been read by the application.

This would enforce "correct" usage of the stream API, and allow applications to more easily track the stream state by just wrapping a quic.Stream. The downside is that this change is pretty subtle, and we really need to make sure that we get it right, otherwise we risk deadlocks if streams don't get garbage collected.

from quic-go.

Another downside is that the stream actually needs to be used (read from and written to). It's possible to just open the HTTP stream, and send and receive datagrams, but that means you'll never observe the state transition.

from quic-go.

Resolved by #4445 and #4460.

from quic-go.