[SignalR] Allow controlling maximum buffer size on client

Background and Motivation

We currently allow control over the “maximum buffer size” on the server: https://docs.microsoft.com/en-us/aspnet/core/signalr/configuration?view=aspnetcore-3.1&tabs=dotnet#advanced-http-configuration-options

(We derive the PauseWriterThreshold and ResumeWriterThreshold values from that).

However, we don’t let the .NET client configure this. We should consider doing so to allow the client better control over backpressure.

This is important for high performance scenarios where the users might be receiving a large batch of data e.g https://github.com/dotnet/aspnetcore/issues/34895 and want to control how much memory is OK to allocate for unprocessed messages.

Proposed API

namespace Microsoft.AspNetCore.Http.Connections.Client
{
    public class HttpConnectionOptions
    {
+        /// <summary>
+        /// Gets or sets the maximum buffer size for data read by the application before backpressure is applied.
+        /// </summary>
+        /// <remarks>
+        /// The default value is 1MB.
+        /// </remarks>
+        public long TransportMaxBufferSize { get; set; }
+        
+        /// <summary>
+        /// Gets or sets the maximum buffer size for data written by the application before backpressure is applied.
+        /// </summary>
+        /// <remarks>
+        /// The default value is 1MB.
+        /// </remarks>
+        public long ApplicationMaxBufferSize { get; set; }
    }
}

Usage Examples

var hubConnection = new HubConnectionBuilder()
                    .WithUrl("http://localhost:5000/chat", o =>
                    {
                        // Set the transport buffer size to 30 MB before yielding
                        o.TransportMaxBufferSize = 1024 * 1024 * 30;
                    })
                    .Build();

Risks

None

Notes:

• This mirrors the properties on the server side, but the naming isn’t great. Transport -> transport to application buffer (inbound) and Application -> application to transport (outbound).

[BrennanConroy]

Right, and if we backport, we can only backport the default value

And also should have an AppContext switch to disable this just in case.

[BrennanConroy]

Right, and if we backport, we can only backport the default value