Runtime: Sockets factories for Connection Abstractions

[scalablecory]

Update: Partially implemented, the remaining parts needs to be revisited. See https://github.com/dotnet/runtime/issues/40044#issuecomment-674193879 -- @antonfirsov

---

Implementation was merged for https://github.com/dotnet/runtime/issues/1793, sans the sockets factories. This tracks the remaining work to implement that issue.

The SocketsConnectionFactory will be trivial to implement: essentially, one must move the implementation over from SocketsHttpConnectionFactory, and make that class inherit from this one.

SocketsListenerFactory can reuse the same SocketsConnection, so 80% of work is already done for that as well.

```c#
class SocketsConnectionFactory : ConnectionFactory
{
// dual-mode IPv6 socket. See Socket(SocketType socketType, ProtocolType protocolType)
public SocketsConnectionFactory(SocketType socketType, ProtocolType protocolType);

// See Socket(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType)
public SocketsConnectionFactory(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType);

// This must be thread-safe!
public override ValueTask<Connection> ConnectAsync(EndPoint? endPoint, IConnectionProperties? options = null, CancellationToken cancellationToken = default);

// These exist to provide an easy way to shim the default behavior.
// Note: Connect must call this to create its socket.
protected virtual Socket CreateSocket(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType, EndPoint? endPoint, IConnectionProperties? options);
protected virtual Stream CreateStream(Socket socket, IConnectionProperties? options);
protected virtual IDuplexPipe CreatePipe(Socket socket, IConnectionProperties? options);

}

class SocketsListenerFactory : ConnectionListenerFactory
{
// dual-mode IPv6 socket. See Socket(SocketType socketType, ProtocolType protocolType)
public SocketsListenerFactory(SocketType socketType, ProtocolType protocolType);

// See Socket(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType)
public SocketsListenerFactory(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType);

// This and the listener's Accept must be thread-safe!
public override ValueTask<ConnectionListener> BindAsync(EndPoint? endPoint, IConnectionProperties? options = null, CancellationToken cancellationToken = default);

// These exist to provide an easy way for users to override default behavior.
// Note: Bind and its listener's Accept must call this to create their sockets.
protected virtual Socket CreateSocket(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType, EndPoint? endPoint, IConnectionProperties? options);

}
```

[msftbot[bot]]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[msftbot[bot]]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[msftbot[bot]]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[AndyPook]

HI,

The current bits (ie under Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.Internal ) all seem to be very focused on supporting "servers".
I've been working with David Fowlers Project Bedrock, but only to create clients for existing services (ie kafka, nats). These kind of project always need to copy SocketConnection from there (see also Orleans) because they are internal.

This issue seems to be about sockets implementations of the "new" abstractions, which is great!
(assuming they will be public ?)

The question... will these be appropriate, both in usage and packaging, for the development of clients (not just servers)?

Thanks,

[scalablecory]

@AndyPook these are public APIs. SocketsConnectionFactory is for client side and SocketsListenerFactory is for server side.

[AndyPook]

awesome, thanks
really looking forward to this

[karelz]

@antonfirsov wants to take it on ...
@geoffkizer can you tell him when it is clear we want both factories in 5.0? (follow up of the ongoing design discussions)

[geoffkizer]

Will do.

[antonfirsov]

@scalablecory what is the right namespace for these?

In the original proposal socket connection stuff has been placed under System.Net.Connections, but SocketsHttpConnectionFactory has landed under System.Net.Http in the PR. Was that a mistake?

[scalablecory]

SocketsHttp... Is HTTP specific.

These two should be in System.Net.Connections.

[antonfirsov]

This got now partially implemented for 5.0.

Leftovers:

1. SocketsListenerFactory
2. Stream and IDuplexPipe factory methods in SocketsConnectionFactory.

During implementation we found uncertainities around the ownership of disposable resources coupled to the IDuplexPipe created by SocketsConnectionFactory but owned by the Connection object. Ownership of the Socket is fine, but if the pipe wraps another disposable resource, then with the current design there is no way to handle it over to the Connection, since IDuplexPipe is not disposable.

We should revisit and probably slightly alter the design of these factory methods before moving on. When figuring out the ownership semantics, we should also think about how GracefulShutdown shall be implemented with user-provided pipes.