Kestrel: Support for multiple transports, side-by-side

[JamesNK]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Kestrel supports being extended to support new transports. This is done by registering IConnectionListenerFactory or IMultiplexedConnectionListenerFactory in DI.

When starting up, for each factory type, Kestrel then gets all registered factories. It then uses the last one for any registered listeners. IConnectionListenerFactory is used for HTTP/1.1 and HTTP/2 endpoints, and IMultiplexedConnectionListenerFactory is used for HTTP/3.

The problem with this is it isn't easily possible to mix transports together. Someone might want to support TCP endpoints using options.ListenLocalhost(80) and a custom transport using options.Listen(new MyCustomEndPoint("address")). Both endpoints are sent to the last factory type.

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddGrpc();
builder.Services.AddSingleton<IConnectionListenerFactory, NamedPipeTransportFactory>();
builder.WebHost.ConfigureKestrel(options =>
{
    options.ListenLocalhost(80); // TCP!
    options.Listen(new NamedPipeEndPoint("Pipe-1")); // Named pipes!
});

var app = builder.Build();

Describe the solution you'd like

I think default interface implementation methods should be added to IConnectionListenerFactory and IMultiplexedConnectionListenerFactory which can be used to test if a factory supports binding a given endpoint.

public interface IConnectionListenerFactory
{
    Task<IConnectionListener> BindAsync(EndPoint endpoint, CancellationToken cancellationToken)
+   public bool CanBind(EndPoint endpoint) => true;
}

public interface IMultiplexedConnectionListenerFactory
{
    Task<IMultiplexedConnectionListener> BindAsync(EndPoint endpoint, CancellationToken cancellationToken)
+   public bool CanBind(EndPoint endpoint) => true;
}

Kestrel continues to get all registered instances of IConnectionListenerFactory and IMultiplexedConnectionListenerFactory from DI, but instead of using the last one registered, Kestrel now keeps all instances, and then when binding a new listener, Kestrel tests each factory with CanBind to see whether it supports binding a given endpoint, then falls back to the next listener.

The new CanBind default implementation returns true, which follows current behavior, and existing factories can override the CanBind method to only allow currently supported addresses. If no factories support an endpoint then Kestrel throws an error saying the endpoint isn't supported.

Additional context

IConnectionListenerFactory and IMultiplexedConnectionListenerFactory are in the Microsoft.AspNetCore.Connections.Abstractions project. It targets netstandard2.0 and .NET Framework. The new DIM would only be available in .NET 8+. Is there precedence for doing this?

[JamesNK]

@davidfowl @Tratcher @halter73

[davidfowl]

What happens if multiple can bind the endpoint type?

[JamesNK]

The last registered factory wins. That's what happens today:

aspnetcore/src/Servers/Kestrel/Core/src/Internal/KestrelServerImpl.cs

Lines 77 to 78 in 9de8e33

	_transportFactory = transportFactories.LastOrDefault();
	_multiplexedTransportFactory = multiplexedFactories?.LastOrDefault();

In the sample below, SocketsTransportFactory is still in DI. Because NamedPipeTransportFactory was registered afterward, it is used for everything. A CanBind method gives an opportunity for unsupported endpoints, e.g. IPEndPoint, UnixDomainSocketEndPoint to fallback.

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddGrpc();
builder.Services.AddSingleton<IConnectionListenerFactory, NamedPipeTransportFactory>(); // <- registered last
builder.WebHost.ConfigureKestrel(options =>
{
    options.Listen(new NamedPipeEndPoint("Pipe-1"), listenOptions =>
    {
        listenOptions.Protocols = HttpProtocols.Http2;
    });
});

var app = builder.Build();

If there are multiple factories that support the same endpoint, then the last one registered wins because CanBind stops falling back.

[davidfowl]

So the logic is that we get all the transports, then we call canbind on all of the endpoints, and the last one that can bind wins?

[JamesNK]

// Reverse so the last registered transport has priority and attempts to bind first
_transportFactories = transportFactories.Reverse().ToList();

public async Task<IConnectionListener> BindAsync(Endpoint endpoint, CancellationToken cancellationToken)
{
    foreach (var factory in _transportFactories)
    {
        if (factory.CanBind(endpoint))
        {
            return await factory.BindAsync(endpoint, cancellationToken);
        }
    }

    throw new InvalidOperationException("Endpoint '{endpoint}' is not supported by any registered transport factory.");
}

[davidfowl]

Or just loop backwards to avoid that allocation 😅

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[halter73]

I like it. Should we label this as ready for API review?

[JamesNK]

Or just loop backwards to avoid that allocation 😅

There is a loop per-bind. Probably cheaper to reverse once and store it as a list and avoid IEnumerable allocation per bind 😋

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[davidfowl]

There is a loop per-bind. Probably cheaper to reverse once and store it as a list and avoid IEnumerable allocation per bind 😋

dotnet/runtime#49970