Unify server and client socket transport

[davidfowl]

The socket transport on the server side is the one used in Kestrel by ASP.NET Core. It's optimized to not allocate and has a memory pool that uses pre-pinned buffers to avoid heap fragmentation. Unfortunately https://github.com/aspnet/AspNetCore/issues/15019 is going to be implemented in .NET 5 but it would be great to have a solution in the mean time that works on 3.1. We should use the same implementation here and have it in the box by default (sockets is by far the most common implementation).

Some options:

1. Copy all of the code for the sockets transport and use it for both the server and the client
2. Copy all of the code for the sockets transport and use it on the client side only (keep the server implementation on the server side).
3. Use private reflection to call into the sockets transport and use it on the client side.
4. Write a new sockets transport and use it for both client and server.

Currently leaning towards 1.

[halter73]

Is option 1 suggesting we ship a new NuGet package with a System.Net.Socket-based IConnectionFactory in addition to an IConnectionListenerFactory that we initially copy from what we currently have in-box? If so, why would that be preferable to option 2? Just so we can iterate on the server as fast as we do on the client?

[davidfowl]

If so, why would that be preferable to option 2? Just so we can iterate on the server as fast as we do on the client?

Yep. Consistent implementation to use on both server and client (since we'll be copying the code anyways) with the ability to makes changes to it in the .net core 3.1 timeframe.

[dangershony]

Hi is issue resolved in the latest commits? Can I treat a client and server connection the same?