Benefits on using UNIX named pipes instead of TCP sockets, in Linux?

Question

Everywhere I read about named pipes vs sockets, I see that a socket can do what a named pipe can, and more. I am guessing that pipes may be faster because they are simpler, but I haven't find it explicitly anywhere.

In Linux, is there any advantage in using named pipes instead of sockets?

Thanks for your help and time.

---

EDIT: I found some comparisons here , but these are UNIX-sockets (aka UNIX domain sockets), which based on this, I understand they are a different creature.

Therefore, I clarify: I am asking about TCP sockets versus Unix named pipes (because MS Windows has another thing called "named pipes", but they seem to be functionally more similar to UNIX domain sockets).

At this point, it looks more likely to me that UNIX named pipes are faster than TCP sockets, but I would like to know some technicalities on why that would the case, and other potential benefits.

Answer 1

This is likely an imperfect answer, but here's what I know.

Sending data over a TCP socket means that the transmission needs to through your networking system, will get a source & destination IP, split up in a maximum of 64K packets. Packaged in both a TCP and IP envelope, potentially go through firewall rules. The receiver also needs to acknowledge packages, make sure they arrive in order and there needs to be a negotation in place in case packages get lost and need to be re-sent.

Sending data in a named pipe more or less works like just writing to a file descriptor like STDOUT, and reading from STDIN.

Going through the network stack (even if it's just localhost) simply has a lot more layers and complexity. The system that can send a message reliably to the other side of the world needs that, but a simple local named pipe does not.

Answer 2

Everywhere I read about named pipes vs sockets, I see that a socket can do what a named pipe can, and more.

Named pipes are used like files.

This is a large benefit if you want to do something that works with a file but it does not work with a socket.

Examples:

ls > /dev/lp1
ls > ./myNamedPipe
# Not possible: ls > 127.0.0.1:9323

dd if=myFile bs=1 count=100 of=/dev/lp1
dd if=myFile bs=1 count=100 of=./myNamedPipe
# Not possible: dd if=myFile bs=1 count=100 of=127.0.0.1:9323

MS Windows has another thing called "named pipes", but they seem to be functionally more similar to UNIX domain sockets

The truth is that MS Windows has additional API functions for accessing named pipes. However, the standard Windows file API (that is used by C functions like open() , read() and write() ) also works with named pipes.

For this reason you can also use a named pipe as file in Windows. I already did that to emulate a serial port with a certain device connected.

... and other potential benefits.

One obvious benefit (of both named pipes and Unix sockets) is the naming itself:

If some program foobarSimpleProgram wants to communicate to another program named foobarOtherProgram , it can simply create a Unix socket or a named pipe named /tmp/foobarProgramSuite .

It's very unlikely that any other program uses this name.

In the case of a TCP socket listening on localhost , the program must either use a fixed TCP port; in this case there is the risk that another program uses the same TCP port so only one of the two programs can be used.

Or the program binds to TCP port 0 so the OS assigns some free TCP port. Then the program writes the port number to a file /tmp/foobarProgramSuite which is read by the other program, which is then doing the connect() .

This is more complicated than directly connecting to the pipe or socket with the given name.