icerpc-csharp icon indicating copy to clipboard operation
icerpc-csharp copied to clipboard

Align Slic connection dispose behavior with Quic

Open bernardnormier opened this issue 3 years ago • 4 comments

See #2183.

In general, I think Slic should behave like Quic whenever doable even if we think the Quic behavior is not the best. We can change Slic and keep in in sync with Quic over time; we have little control over .NET's Quic implementation.

In this particular case, SlicConnection.DisposeAsync should send a Close frame like Quic (or Quic will soon). The application error code would be a "default error code" set in the Slic options.

bernardnormier avatar Dec 07 '22 16:12 bernardnormier

    Really: the "accept requests loop" (or accept requests task) disposed the transport connection while this CloseAsync was in progress.

And presumably, transportConnection.DisposeAsync does not wait for an outstanding CloseAsync to complete: it aborts it. Is this the correct semantics for multiplexed connection?

See also https://github.com/dotnet/runtime/issues/78641#issuecomment-1322506759

Originally posted by @bernardnormier in https://github.com/zeroc-ice/icerpc-csharp/pull/2289#discussion_r1047697582

bentoi avatar Dec 14 '22 08:12 bentoi

Microsoft does not describe what they want to do when DisposeAsync is called while CloseAsync is in progress. Presumably it could be: a) wait for the CloseAsync to complete b) somehow abort the CloseAsync and wait for this aborted CloseAsync to complete

We should ask Manicka on this issue 78641.

And once we know, we do the same in Slic.

bernardnormier avatar Dec 29 '22 21:12 bernardnormier

The protocol connection disposal is now abortive like Slic. If we allow the transport DisposeAsync to be graceful, would there still be a good reason for IProtocolConnection.DisposeAsync to not be graceful like Quic (graceful if ShutdownAsync didn't previous fail or was not called)?

Or should we push for a silent close implementation of QuicConnetion.DisposeAsync?

I'm moving to 0.2 for now.

bentoi avatar Mar 01 '23 11:03 bentoi

See https://github.com/dotnet/runtime/pull/96807 that fixes the issue I reported. We need to review how these changes are relevant with this issue.

For instance, SlicConnection.DisposeAsync is already abortive so Quic is now aligned with Slic. It's not clear however, if Quic and Slic behave the same when DisposeAsync is called while a CloseAsync call is in progress, it's likely.

bentoi avatar Jan 30 '24 11:01 bentoi