Reintroduce Socket.DuplicateAndClose() on Windows

[antonfirsov]

In Framework we had DuplicateAndClose and a matching Socket(SocketInformation) constructor to allow transferring sockets to other Win32 processes.

.NET Core does not support this method because of the reasons described in the linked comments.

Upon the request of two internal partners we propose to reintroduce a constrained implementation with the following limitations/differences:

• Socket duplication does not work with IOCP on OS level. In Framework it was possible to set socket.UseOnlyOverlappedIO = true to ensure that no completion ports are bound to the socket. This will be not supported in .NET Core, since the entire Windows implementation of async IO is based on IOCP.
• The solution will be Windows-only, because the original design of SocketInformation API-s is strongly specific to that platform.
  • Note: To support this scenario on Unix, we should implement Consider exposing Socket(SafeSocketHandle fd) constructor #862 and provide an in-box solution for Sending file descriptors on unix sockets #932, but these requests shall be tracked independently from DuplicateAndClose.

Proposal for preventing invalid usages

It's not possible to use asynchronous operations in both the original and the duplicate socket because of platform limitations in IOCP.

Framework behavior

await server.ReceiveAsync(receiveBuffer, SocketFlags.None);
SocketInformation info = server.DuplicateAndClose(procId);
Socket cloneServer = new Socket(info);

// throws mysterious, undocumented ArgumentException:
await cloneServer.ReceiveAsync(receiveBuffer, SocketFlags.None);

[EDIT] New propsal

await server.ReceiveAsync(receiveBuffer, SocketFlags.None);
SocketInformation info = server.DuplicateAndClose(procId);
Socket cloneServer = new Socket(info);

// Detect the corner case and throw InvalidOperationException
await cloneServer.ReceiveAsync(receiveBuffer, SocketFlags.None);

[EDIT] Original proposal

await server.ReceiveAsync(receiveBuffer, SocketFlags.None);

// throw InvalidOperationException in advance:
SocketInformation info = server.DuplicateAndClose(procId);

The downside of this design would be that we would prevent cloning a socket (previously used asynchronously) to be used for synchronous operations after being cloned. This is a very unlikely scenario though.

[scalablecory]

throw InvalidOperationException in advance

Are you able use existing state to do this? E.g. checking if the socket has a ThreadPoolBoundHandle.

The downside of this design would be that we would prevent cloning a socket (previously used asynchronously) to be used for synchronous operations after being cloned. This is a very unlikely scenario though.

I don't know how unlikely this is. If we wanted to enable this scenario, what would we need to do?

[antonfirsov]

Are you able use existing state to do this? E.g. checking if the socket has a ThreadPoolBoundHandle.

Yes, SafeSocketHandle.IOCPBoundHandle is the ThreadPoolBoundHandle that is null until the very first asynchronous operation.

I don't know how unlikely this is. If we wanted to enable this scenario, what would we need to do?

The problem is logically similar to dotnet/corefx#42609. Instead of throwing in DuplicateAndClose, we either need to transfer an additional state flag in SocketInformation and explicitly watch it in async operations in the clone socket, or try to convert the internal ArgumentException to something more reasonable.

[scalablecory]

The problem is logically similar to dotnet/corefx#42609.

It's similar in that you'd get fast-failure, but dissimilar in that using sync APIs on a socket that has been duplicated is a valid use.

try to convert the internal ArgumentException to something more reasonable.

Can we prototype what this would look like?

What I'm thinking is that users of DuplicateAndClose will probably have very specific scenarios that I'm not sure we can predict; disabling something that worked in the past might mean another issue down the road as more and more people migrate away from Framework. It's worth weighing the pros/cons of cleaning up the API vs keeping it compatible.

[antonfirsov]

@scalablecory looks like it's possible to detect the specific case. I will throw InvalidOperationException when it's not possible to bind the socket to an IOCP. This will also help with #862 corner cases.