Named pipe
From Wikipedia, the free encyclopedia
In computing, a named pipe (also FIFO for its behaviour) is an extension to the traditional pipe concept on Unix and Unix-like systems, and is one of the methods of inter-process communication. The concept is also found in Microsoft Windows, although the semantics differ substantially. A traditional pipe is "unnamed" because it exists anonymously and persists only for as long as the process is running. A named pipe is system-persistent and exists beyond the life of the process and must be "unlinked" or deleted once it is no longer being used. Processes generally attach to the named pipe (usually appearing as a file) to perform IPC (inter-process communication).
Contents |
[edit] Named pipes in Unix
Instead of a conventional, unnamed, shell pipeline, a named pipeline is explicitly created using mkfifo() or mknod(), and two separate processes can access the pipe by name.
For example, one can create a pipe and set up gzip to compress things piped to it:
mkfifo my_pipe gzip -9 -c < my_pipe > out.gz rm my_pipe
In a separate process shell, independently, one could send the data to be compressed:
cat file > my_pipe
[edit] Named pipes in Windows
In Windows, the design of named pipes is biased towards client-server communication, and they work much like sockets, other than the usual read and write operations. Windows named pipes also support an explicit "passive" mode for server applications (compare: Unix domain sockets). Windows 95 supports named pipe clients, Windows NT based systems can also be servers.
The named pipe can be accessed much like a file. Win32 SDK functions such as CreateFile, ReadFile, WriteFile and CloseHandle can be used to open, read from, write to, and close a pipe. C library functions such as fopen, fread, fwrite, and fclose can also be used, unlike Windows Sockets, which does not implement network use of standard file i/o operations. There is no command line interface like Unix.
Named pipes aren't permanent and can't be created as special files on any writable filesystem, unlike in Unix, but are volatile names (freed after the last reference to them is closed) allocated in the root directory of the named pipe filesystem (NPFS), mounted under the special path \\.\pipe\ (that is, a pipe named "foo" would have a full path name of \\.\pipe\foo). Anonymous pipes used in pipelining are actually named pipes with a random name.
They are very rarely seen by users, but there are notable exceptions. The VMware Workstation PC hardware virtualization tool, for instance, can expose emulated serial ports to the host system as named pipes, and the WinDbg kernel mode debugger from Microsoft supports named pipes as a transport for debugging sessions (in fact, VMware and WinDbg can be coupled together - since WinDbg normally requires a serial connection to the target computer - letting driver developers do their development and testing on a single computer). Both programs require the user to enter names in the \\.\pipe\name form.
Windows NT Named Pipes can inherit a security context.
Summary of named pipes on Microsoft Windows:
- Intermachine and Intramachine IPC
- Full-Duplex
- Byte-oriented or Message-oriented
- Reliable
- Blocking or Nonblocking read and write (choosable)
- Standard device IO handles (
FileRead,FileWrite) - Namespace used to create handles
- Inefficient WAN traffic (explicit data transfer request, unlike e.g. TCP/IP sliding window etc.)
- Peekable reads (read without removing from pipe's input buffer)
[edit] Named pipes in Windows networking
Named Pipes is also a networking protocol in the Server Message Block (SMB) suite, based on the use of a special Inter-process communication (IPC) share. SMB's IPC can seamlessly and transparently pass the authentication context of the user across to Named Pipes. Windows NT's entire NT Domain protocol suite of services are implemented as DCE/RPC services over Named Pipes, as are the Exchange 5.5 Administrative applications.
Windows NT Named Pipe authentication inheritance is sufficiently opaque and seamless to the user and developer perspective as to be nearly invisible, and consequently it is frequently misunderstood.
