Configure the Accept Socket

[shirhatti]

This issue is inspired by @deanward81's post at https://bakedbean.org.uk/posts/2021-05-airdrop-anywhere-part-3/

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

We recently exposed the Listen socket via a connection feature. In similar vein, we should probably also expose the Listen Socket via a server feature.

The workaround today is to replace the TransportFactory (code snippet copied from the blog post)

// Actual implementation: https://github.com/deanward81/AirDropAnywhere/blob/2021-05-17-receiving-files/src/AirDropAnywhere.Core/HttpTransport/AwdlSocketTransportFactory.cs
internal class AwdlSocketTransportFactory : IConnectionListenerFactory
{
    private readonly IConnectionListenerFactory _connectionListenerFactory;
    private readonly FieldInfo _listenSocketField;
    
    public AwdlSocketTransportFactory(IOptions<SocketTransportOptions> options, ILoggerFactory loggerFactory)
    {
        _connectionListenerFactory = new SocketTransportFactory(options, loggerFactory);
        // HACK: this merry little reflective dance is because of sealed internal classes
        // and no extensibility points, yay :/
        _listenSocketField = typeof(SocketTransportFactory).Assembly
            .GetType("Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener")
            .GetField("_listenSocket", BindingFlags.Instance | BindingFlags.NonPublic);
    }

    public async ValueTask<IConnectionListener> BindAsync(EndPoint endpoint, CancellationToken cancellationToken = default)
    {
        var transport = await _connectionListenerFactory.BindAsync(endpoint, cancellationToken);
        // HACK: fix up the listen socket to support listening on AWDL
        var listenSocket = (Socket?) _listenSocketField.GetValue(transport);
        if (listenSocket != null)
        {
            listenSocket.SetAwdlSocketOption();
        }
        return transport;
    }
}

Describe the solution you'd like

I haven't thought this through yet. 😅 I know an IStartupFilter is too early since the server hasn't started yet

Additional context

Here's a fun read: https://bakedbean.org.uk/posts/2021-05-airdrop-anywhere-part-3/

[Tratcher]

It would need to be some kind of callback on the SocketTransportOptions. Features only come into play after accepting a connection.

[halter73]

Why not just use ListenHandle?

[shirhatti]

Something like this?

webBuilder.ConfigureKestrel(options =>
{
    
    if (!RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
    {
        var ipAddress = new IPEndPoint(IPAddress.Loopback, 5000);
        var socket = new Socket(ipAddress.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
        // modify socket options
        options.ListenHandle((ulong)socket.SafeHandle.DangerousGetHandle().ToInt32());
    }

});

[shirhatti]

Alternatively, how about a KestrelServerOptions.Listen() overload that accepts a listen socket?

[halter73]

Yeah. A Socket overload to Listen might also be interesting.

One advantage to doing this as a server feature is that it would work with our normal address binding logic, but then we'd probably want to introduce a way to interact with the socket between binding and listening. I'm not sure how we'd do that.

[davidfowl]

It would need to be some kind of callback on the SocketTransportOptions. Features only come into play after accepting a connection.

👍🏾

public class SocketTransportOptions
{
+    public Action<EndPoint, Socket> ConfigureAcceptSocket { get; set; }
}

[halter73]

That is a pretty good way to do that. Nice suggestion @Tratcher 😄 I think we should call it ConfigureListenSocket to disambiguate between the connection socket being accepted vs the listen socket we're calling accept on.

[deanward81]

I wanted to play with .NET 6 in my side project (from the blog post) so added both ConfigureListenSocket and ConfigureAcceptSocket to test my AirDrop shennanigans with. Seems to be working well on my end so I just added a PR for it.

Thanks for contacting us.

We're moving this issue to the Next sprint 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.