What are the advantages of using named pipe over unnamed pipe?

Named pipes (fifo) have four three advantages I can think of:

• you don't have to start the reading/writing processes at the same time
• you can have multiple readers/writers which do not need common ancestry
• as a file you can control ownership and permissions

• they are bi-directional, unnamed pipes may be unidirectional *

  ^{*) Think of a standard shell | pipeline which is unidirectional, several shells (ksh, zsh, and bash) also offer coprocesses which allow bi-directional communication. POSIX treats pipes as half-duplex (i.e. each side can only read or write), the pipe() system call returns two file handles and you may be required to treat one as read-only and the other as write-only. Some (BSD) systems support read and write simultaneously (not forbidden by POSIX), on others you would need two pipes, one for each direction. Check your pipe(), popen() and possibly popen2() man pages. The undirectionality may not be dependent on whether the pipe is named or not, though on Linux 2.6 it is dependent.}

(Updated, thanks to feedback from Stephane Chazelas)

So one immediately obvious task you cannot achieve with an unnamed pipe is a conventional client/server application.

The last (stricken) point above about unidirectional pipes is relevant on Linux, POSIX (see popen()) says that a pipe need only be readable or writeable, on Linux they are unidirectional. See Understanding The Linux Kernel (3rd Ed. O'Reilly) for Linux-specific details (p787). Other OS's offer bidirectional (unnamed) pipes.

As an example, Nagios uses a fifo for its command file. Various external processes (CGI scripts, external checks, NRPE etc) write commands/updates to this fifo and these are processed by the persistent Nagios process.

Named pipes have features not unlike TCP connections, but there are important differences. Because a fifo has a persistent filesystem name you can write to it even when there is no reader, admittedly the writes will block (without async or non-blocking I/O), though you won't loose data if the receiver isn't started (or is being restarted).

For reference, see also Unix domain sockets, and the answer to this Stackoverflow question which summarises the main IPC methods, and this one which talks about popen()

Unnamed or anonymous pipes provide a means of one-to-one, one-way interprocess communication between different processes that are related by either a parent-child relationship, or by being children of a common parent that provides the pipe, such as a shell process. Because the processes are related, the association of file descriptors to the pipe can be implicit and does not require an object with a name that is external to the processes. An unnamed pipe exists only as long as the processess that use it maintain open file descriptors to the pipe. When the processes exit and the OS closes all of the file descriptors associated with the processes, the unnamed pipe is closed.

Named pipes are in fact FIFO's. These are persistent objects represented by nodes in the file system. A named pipe provides many-to-many, two-way communication between one or more processes that are not necessarily related and do not need to exist at the same time. The file name of the pipe serves as an address or contract between the processes for communication. If only one process writes to a named pipe and one other process reads from the named pipe, then the named pipe behaves in the same way as an unnamed pipe between the two related processes.

So the short answer is that you need a named pipe for communication between unrelated processes that might not exist at the same time.

There is another advantage of named pipes: you can use them across different systems. Suppose you want real-time communication of two process running on different machines. Then share a folder between the two, put your FIFO onto the folder, and off you go. It is considerably easier than transforming an application designed to work on files into a service listening on a port.