[QUIC] QuicStream.ReadAsync against an aborted connection returns End Of Stream

[scalablecory]

ReadAsync() will return 0, which indicates end of stream, when a connection was aborted. It should be throwing QuicConnectionAbortedException.

[jkotalik]

@nibanks, when closing a connection in quic with a non-zero error code, does that propagate up to streams at all? Right now it looks like in msquic, an event occurs on the connection with an error code, but that doesn't propagate up to the streams; streams just close.

[nibanks]

@jkotalik nope. Streams and connections have separate error code spaces. If you shutdown the connection with an error, the peer streams just get shutdown complete events, and the connection gets the peer shutdown with the error code.

[jkotalik]

Hm, interesting. So if the peer shuts down a connection, are streams gracefully or abortively shut down? To me, if we just get shutdown/ shutdown complete events, it seems graceful even though we are "aborting" the connection.

[nibanks]

As far as QUIC is concerned, there is no such thing as "aborting" a connection. The app shuts it down with an error code. There are no "good" or "bad" error codes. When you shut down a connection with currently opened streams, the streams are implicitly shutdown, but since no app-specific error code was given to shut down the stream by the peer, none is delivered to the app. They are just implicitly shut down, and the corresponding events are delivered to the app.

[ManickaP]

Meeting notes:

• Msquic is event-based, instead of calling Read we get an event that more data is available. We should also get an event about connection being closed. If we see that connection is closed, we should throw an exception from our Read instead of returning 0.
• We also want to differentiate upon us closing vs peer closing, we should propagate error code in case of peer closing.
• The only event that doesn't have error code is Shutdown Complete, but it is a result of our shutdown.
• We decided for now to let the user track their own error codes and not round-tripping them back (in e.g. ObjectDisposedException) but we may add that later