Consider exposing Socket(SafeSocketHandle fd) constructor

[dmirmilshteyn]

---

EDIT: Revised proposal by @stephentoub on 4/3/2020:

public Socket(SafeSocketHandle handle);

---

System.Net.Sockets.Socket currently does not expose any mechanism to instantiate a socket from an existing file descriptor/handle. This proposal aims to expose this functionality to improve interop with external applications that manage socket connections.

Rationale and Usage

Currently, a socket must be both created and managed by the user application. While this is desired behaviour in most cases, there is no mechanism to take an existing socket handle/file descriptor and make use of it within the user application. If one wanted to use a socket that was created by an external application, the only option (outside of reflection hacks) is to reimplement the calls to the underlying platform sockets with P/Invoke - largely removing the benefits that the managed socket classes provide.

More specifically, this improves interop with existing applications that manage socket connections, such as systemd and the socket activation feature. In this scenario, systemd creates an unmanaged socket to listen for connections. Once a connection is established, a .NET application is launched and a file descriptor that references the unmanaged socked is passed to it through environment variables. Without the ability to create a managed socket from a file descriptor, the connection will need to be reset and then reestablished using the managed APIs - rather than cleanly being passed through and maintained.

Proposed API

namespace System.Net.Sockets
{
    // Previously implemented socket class
    public partial class Socket : System.IDisposable
    {
        // Existing constructors
        public Socket(System.Net.Sockets.AddressFamily addressFamily, System.Net.Sockets.SocketType socketType, System.Net.Sockets.ProtocolType protocolType) { }
        public Socket(System.Net.Sockets.SocketInformation socketInformation) { }
        public Socket(System.Net.Sockets.SocketType socketType, System.Net.Sockets.ProtocolType protocolType) { }   
        private Socket(SafeCloseSocket fd) { }

        // Additional existing members omitted

        // Proposed member
        public Socket(IntPtr fileDescriptor, AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType) { }
    }
}

Details

• Adding this rather than exposing the existing Socket(SafeCloseSocket fd) constructor will keep the rest of the socket PAL internal, as there's currently public no way (as far as I can tell) to create an instance of SafeCloseSocket from a IntPtr.
• This will align with user expectations coming from other languages, such as Python, which has a similar method to create a socket from a file descriptor (see socket.fromfd(fd, family, type[, proto])).
• Platforms that don't support wrapping unmanaged sockets (or that don't expose them, such as UWP?) will throw PlatformNotSupportedException.

[davidsh]

Please take a look at:
https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/adding-api-guidelines.md

for API change process and submit API proposal.

[geoffkizer]

I agree, this would be a good feature to have.

[karelz]

Next step: We need formal API proposal (linked above)

[dmirmilshteyn]

@karelz Here's the proposal. This is my first contribution here, so please let me know if I need to add more details/adjustments.

Proposal: Add a new constructor to System.Net.Sockets.Socket that allows instantiating a socket from a file descriptor. I imagine this would also need to be added to the next netstandard version, but this shouldn't introduce any extra dependencies/other breaking API changes.

public Socket(IntPtr fileDescriptor, AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType)

Adding this rather than exposing the existing Socket(SafeCloseSocket fd) constructor will keep the rest of the socket PAL internal, as there's currently public no way (as far as I can tell) to create an instance of SafeCloseSocket from a IntPtr. This will also align with user expectations coming from other languages, such as Python, which has a similar method to create a socket from a file descriptor (see socket.fromfd).

Use cases: support features where external programs manage socket connections (such as systemd socket activation), improved interop with native code and existing unix tools

[karelz]

Can you please use the API template in API process? It's much, much easier to read ;) Thanks!
Also please copy/move it into the top post - it is easier to find the latest version of the proposal.

[geoffkizer]

@stephentoub Thoughts on this?

[dmirmilshteyn]

@karelz I've updated the top post based on the example from that document.

[karelz]

Great, thank you!

Does the fileDescriptor always match OS bitness on all OSs - Windows, Linux and Mac OS APIs?

@davidsh @geoffkizer @CIPop @Priya91 please comment or give thumbs up, thanks!

[stephentoub]

Does the fileDescriptor always match OS bitness on all OSs - Windows, Linux and Mac OS APIs?

file descriptors on Unix are <= 32K. Since handles in Windows are represented as pointers, we've been using IntPtr everywhere in corefx to represent both, which allows us to use SafeHandle for them.

@stephentoub Thoughts on this?

Seems like an ok API to expose.

One modification though:
I would suggest that the ctor take a SafeHandle rather than a raw IntPtr. The plan for https://github.com/dotnet/corefx/issues/13470, which has been approved but not yet implemented, is to expose a SafeSocketHandle (probably just rename SafeCloseSocket). Taking a SafeHandle like this will make ownership clearer. Just taking an IntPtr, is the socket responsible for closing the socket when Socket is disposed or not? So you'd also need to take an ownsHandle flag or something similar, and the Socket will end up creating a SafeSocketHandle anyway under the covers.

Related to this, I also wonder if there are implicit assumptions in Socket's implementation related to lifetime. I expect some vetting of the implementation will need to be done and it won't be quite as simple as just adding a ctor, though it may turn out to be all the actual code that's needed.

[tmds]

Perhaps also consider a public Socket(SafeCloseSocket)?

On Linux, the address family, socket type and protocol can be retrieved as SO_DOMAIN, SO_PROTOCOL, SO_TYPE. SO_TYPE is POSIX, the other two are not.
When the OS does not support retrieving the values, they can be set to the enums Unknown value.

[orthoxerox]

👍 to this. I've been looking for a way to restart an application without losing open TCP connections, and while Process.Start() ensures the child process inherits all the handles, it cannot access the open sockets.

[Tragetaschen]

I've got my DBus client and get a file descriptor from BlueZ representing the RFCOMM socket when a smart phone connects to a registered Bluetooth profile. I would love to work with this using all the socket goodness instead of wrapping it in a Stream and providing the bare minimum read and write pinvokes by myself.

[stephentoub]

cc: @wfurt