Benoit Foucher

I've merged my changes to your branch. The issue is that I can't move the stream into the lambda. The following doesn't work: ```cpp [self, outAsync = outAsync->shared_from_this(), stream =...

> This is both accurate and the correct behavior. Merely receiving a protocol frame does not make a connection "not at rest". This frame must be an (incoming) request for...

> The IceRPC code is much simpler. In IceProtocolConnection.cs, we call DecrementDispatchInvocationCount when an invocation is complete (e.g. after reading the reply): Ok, it's not obvious from reading the code...

FYI, they added KeepAliveInterval which I believe can be used for this purpose: https://github.com/dotnet/runtime/pull/94211

See also https://www.bleepingcomputer.com/news/security/new-http-2-flaws-expose-unpatched-web-servers-to-dos-attacks/

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...

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...

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...

> It should indeed complete quickly (not CPU intensive), but it seems gratuitous to execute this code in the read loop. See also https://github.com/icerpc/icerpc-csharp/pull/3348#discussion_r1227099748 Should the read frame loop just...