This is still the header! Main site

Named Pipes

2021/04/14

... this is Part 2 of the "why sockets are stupid" series; here is Part 1.

... named what?

Named pipes are kind of like Unix domain sockets on Windows. You can open one, open the other end in another process, and send bytes through (... possibly also receive them, in duplex mode). All this is fairly boring: ... sure, it's the weird Windows version of Unix sockets, which are better in every possible way, end of story.

And yet... it might be worth taking a quick look at the differences. There is enough of them that Microsoft is actually reimplementing Unix sockets on Windows, to make porting code easier.

For example, unlike Unix sockets, where you open one end and you can just connect with as many clients as you want, each named pipe is an instance: you have to create one at the server side for each client. Once created, this "pool" shares a name, but they're still separate instances; you get an error on the client side if the pool runs out.

They also differ in terms of namespace. While on Unix, sockets look kind of like a file, on the actual file system, named pipes occupy an entirely different namespace of \\machinename\pipe\name_of_pipe. Although this looks like a directory hierarchy, it isn't one: there is only one level, with unique names. (At least you can give them looong names: 256ish characters.)

As one might expect from an OS-specific IPC mechanism, they do come with actual access control. With Unix sockets, you can connect to them only if you have permission to access the socket on the file system, just as if it was a file. The Windows version is kind of similar: you can have the same descriptors on them as on files themselves, although, since they're sitting in a different namespace, they do not inherit anything by default. Additionally, it looks like it's fairly easy to leave them accessible to anyone, making them an excellent source of security holes. So... Unix wins again, riight...?

Here comes the magic

Remember that \\machinename\pipe\name_of_pipe naming scheme? Actually, if you don't want to add the name of the machine, you can just use \\.\pipe\name_of_pipe. However... given how this is supposed to be an article about sockets, among other things... you might suspect something...

Well, yes. They do work over a network.. You can just, on \\my-machine, connect to the named pipe \\your-machine\pipe\some-pipe, and it'll just work. Better yet, you'll get the same access control as with local connections: basically, we're using the same mechanisms as file shares etc, so if you're in the same domain, it'll just magically work, while if you aren't, you can still give it a username and a password.

They also have another fancy feature that Unix sockets don't: if everything is set up well, the server process can impersonate the client, temporarily gaining the same rights. Apparently, this is the slightly extended, Windows version of the Unix "let's just figure out what user is on the other end" APIs.

Of course, nothing comes without downsides. Apparently, pipe traffic was either unencrypted for quite some time, or it might still be unencrypted; use of SSL on them might be a good idea when using them remotely, adding another unwieldy layer to an otherwise fairly convenient OS facility. Also, the default-everything-is-open stance might have resulted in just enough security issues, so locking these down seems to be becoming the norm.

Why is this interesting?

(... and here come the subjective opinions.)

First of all: observe the fact that named pipes have names. It's a whole lot easier to make up a unique 256-byte name as compared to squabbling over 65535 sockets. However, their names are not as fancy as those of Unix domain sockets, which fit into a file hierarchy somewhat better.

There are also other differences. Apparently, TCP/IP works a whole lot better with nontrivial latencies, for "remote" use cases (as per random sites commenting on this). However...

... after entire minutes of trying to find the answer, I'm still not drastically sure how they're transported over a network. Yes I should probably fire up some Windows VMs and Wireshark. Also, there is this piece of MS documentation on SMB2, describing named pipe requests; to me it does look like it's happening over SMB.

"SMB the file system sharing protocol" that is. Which is yet another interesting topic: SMB can actually do multiple things, including remote procedure calls, printing, sharing of serial ports of all things, and, apparently, named pipes.

It's interesting to observe how non-Unix this is. Basically, each Unix service description sounds like "service X runs over TCP socket 12345"... even in the case of NFS, which is based on some archaic RPC mechanism, the assumption is that there is an actual protocol underneath. Meanwhile, here, what we have is the API: there are some OS services connecting some machines, and you can use the result. Just like the way you don't expose how you get from one CPU core onto another on a Unix box.

In fact, this might not be a coincidence. SMB looks like a stupidly overcomplicated protocol, with words like NetBIOS and NetBEUI flying out of some long-forgotten brain areas. These days, it's obviously a thing over TCP, just like everything else is. However... back in the olden days, SMB was running on different stacks... e.g. on smaller networks, there was no TCP underneath whatsoever. No sockets.

Also, for all the talk of "named pipes are not files", they're accessible via networks, while Unix domain sockets aren't, providing the same kind of access control, over the same protocol as you're using to access files. As if...

... named pipes are less like "files" from the same machine, but more like files from other machines, compared to Unix-y communication methods?

So... what we have is a... form of communication that:

Nevertheless:

Wouldn't it be nice to combine all the benefits, fix the downsides, and come up with something that is better than our current sockets + everything-over-HTTP abomination?

This is post no. 4 for Kev Quirk's #100DaysToOffload challenge.

... comments welcome, either in email or on the (eventual) Mastodon post on Fosstodon.