Unix domain sockets on Windows

I just found out from a tweet from David Fowler that Windows is getting support for Unix domain sockets, which is pretty amazing. Unix domain sockets are an inter-process communication (IPC) feature that use the file-system as an address space, and file-system permissions for security. Other than that, they generally work like regular network sockets. Lots of Linux software uses domain sockets for local connections; for example, Docker creates a /var/run/docker.sock socket for communicating with the daemon on the local machine. It’s more secure, incurs less system overhead and is also faster than running on a localhost TCP socket.

The Windows implementation will initially support the Stream type of socket, which is like TCP, and it appears that .NET Core is going to support Unix domain sockets on Windows pretty rapidly (it already has support for Unix domain sockets on Linux).

From the WCF point of view, this sounds like it could be a promising replacement for Named Pipe bindings, which are used for on-host IPC on Windows. Named Pipes are not Sockets, so things like HTTP servers (e.g. Kestrel) don’t support them. With Unix domain sockets, running a Kestrel HTTP/2 server, whether for regular HTTP APIs or for gRPC, is just a matter of setting options:

.UseKestrel(options =>
{
    options.ListenUnixSocket("/var/run/myapp.sock");
})

At present, Unix domain sockets are only supported in the latest Insider builds of Windows 10, so once the support lands in a .NET Core 3 preview, I’ll fire up a VM and take it for a spin, and post some performance comparisons between WCF Named Pipe bindings and .NET Core gRPC over Unix sockets.

Any questions?

If you’re currently using WCF at your organization and have a specific scenario you are considering reworking for .NET Core 3.0 or .NET 5, I’d love it if you’d ping me on Twitter (@markrendle) and tell me about it.