Connection close and stream data

[ManickaP]

Few questions on MsQuic internal behavior came up during our .NET discussion and we were wondering if you could shed light on them:

• What happens with stream data that are buffered, but not yet indicated to the user when the connection gets closed?
• Will they get discarded, because connection closure supersedes any stream events?
• Is there a difference based on which side closed the connection?
• Is there a difference based on which data were ACKed and which weren't?
• Does received FIN flag play any role in it?

I'm aware that the connection should be given enough time to process all streams (e.g. idle out). But we are discussing corner scenarios and we want to make sure the .NET layer is not doing anything out of expectations for QUIC layer.

cc @wfurt @CarnaViire

[nibanks]

Please clarify what you mean by "connection gets closed". Do you mean aborted/reset? Or do you mean gracefully shutdown? Aborted will abandon anything buffered. Graceful will not.

[nibanks]

You will get a send complete with the Canceled flag set.

[ManickaP]

Thank you!

[nibanks]

You're welcome!

[CarnaViire]

Yes, abortive shutdown of a stream discards everything else queued for either send or receive.

But if we received FIN flag, doesn't it put stream's receive side into successful completion state? would that state be overridden?

What I mean is: writing side is still open and on reading side, the data, including FIN flag, is received by MsQuic but not fully handed down to user yet (e.g., callback for RECEIVE event returned Pending). Then peer tears down the connection. What will happen in that case?

[CarnaViire]

Also, from what I see in https://www.rfc-editor.org/rfc/rfc9000.html#section-3.2-13, it is up to the implementation to decide whether to discard the buffered data+FIN in case the stream is reset (or connection is closed), or to keep it and hand down to the user. Is that correct?