Skip to content

Flush ACKs on Stream Closure #3842

Open
Open
@CarnaViire

Description

@CarnaViire

Describe the feature you'd like supported

Discovered in dotnet/runtime#71927

Fot HTTP/3 in .NET, which uses MsQuic underneath, client connection closure would happen in Dispose of an HttpClient. However, due to various circumstances, either due to an app being a short one-liner (e.g. PowerShell script) or a client being a shared singleton (e.g. a proposal in dotnet/runtime#65380), the app will most possibly not dispose the HttpClient. That might lead to the last ACK, if it was delayed past the stream closure, never being sent to the server.

The problem would manifest on the server side by the server stream trying to resend the last packets in a hope to get the ack, but never getting it will lead to a connection being torn down in a non-graceful way and the request would deem to be unsuccessful (despite it being successful on the client side). This would lead to the server stream living longer and wasting time on resending packets, as well as unnecessary errors in the logs.

For more information, see the initial issue, where it was observed on a gRPC server: dotnet/runtime#71927

Proposed solution

Flush ACKs on Stream Closure, either always or if a feature flag was set

Additional context

A draft was started in #2904. End-to-end tests have shown that in order for this to work, the code should be in Close, not Shutdown (see dotnet/runtime#71927 (comment)).

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area: CoreRelated to the shared, core protocol logicPartner: .NETBy or For the .NET teamfeature requestA request for new functionality

    Type

    Projects

    Status

    No status

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions