This article includes a list of references, but its sources remain unclear because it has insufficient inline citations. (August 2015) (Learn how and when to remove this template message)
In computer science, inter-process communication or interprocess communication (IPC) refers specifically to the mechanisms an operating system provides to allow the processes to manage shared data. Typically, applications can use IPC, categorized as clients and servers, where the client requests data and the server responds to client requests. Many applications are both clients and servers, as commonly seen in distributed computing. Methods for doing IPC are divided into categories which vary based on software requirements, such as performance and modularity requirements, and system circumstances, such as network bandwidth and latency.
IPC is very important to the design process for microkernels and nanokernels. Microkernels reduce the number of functionalities provided by the kernel. Those functionalities are then obtained by communicating with servers via IPC, increasing drastically the number of IPC compared to a regular monolithic kernel.
|Method||Short Description||Provided by (operating systems or other environments)|
|File||A record stored on disk, or a record synthesized on demand by a file server, which can be accessed by multiple processes.||Most operating systems|
|Communications file||A unique, late-1960's form of inter-process communication, most closely resembling Plan 9's 9P protocol||Dartmouth Time-Sharing System|
|Signal; also Asynchronous System Trap||A system message sent from one process to another, not usually used to transfer data but instead used to remotely command the partnered process.||Most operating systems|
|Socket||Data sent over a network interface, either to a different process on the same computer or to another computer on the network. Stream-oriented (TCP; data written through a socket requires formatting to preserve message boundaries) or more rarely message-oriented (UDP, SCTP).||Most operating systems|
|Unix domain socket||Similar to an internet socket but all communication occurs within the kernel. Domain sockets use the file system as their address space. Processes reference a domain socket as an inode, and multiple processes can communicate with one socket||All POSIX operating systems and Windows 10|
|Message queue||A data stream similar to a socket, but which usually preserves message boundaries. Typically implemented by the operating system, they allow multiple processes to read and write to the message queue without being directly connected to each other.||Most operating systems|
|Pipe||A unidirectional data channel. Data written to the write end of the pipe is buffered by the operating system until it is read from the read end of the pipe. Two-way data streams between processes can be achieved by creating two pipes utilizing standard input and output.||All POSIX systems, Windows|
|Named pipe||A pipe implemented through a file on the file system instead of standard input and output. Multiple processes can read and write to the file as a buffer for IPC data.||All POSIX systems, Windows, AmigaOS 2.0+|
|Shared memory||Multiple processes are given access to the same block of memory which creates a shared buffer for the processes to communicate with each other.||All POSIX systems, Windows|
|Message passing||Allows multiple programs to communicate using message queues and/or non-OS managed channels, commonly used in concurrency models.||Used in RPC, RMI, and MPI paradigms, Java RMI, CORBA, DDS, MSMQ, MailSlots, QNX, others|
|Memory-mapped file||A file mapped to RAM and can be modified by changing memory addresses directly instead of outputting to a stream. This shares the same benefits as a standard file.||All POSIX systems, Windows|
Depending on the solution, an IPC mechanism may provide synchronization or leave it up to processes and threads to communicate amongst themselves (e.g. via shared memory).
While synchronization will include some information (e.g. whether or not the lock is enabled, a count of processes waiting, etc.) it is not primarily an information-passing communication mechanism per se.
Examples of synchronization primitives are:
Remote procedure call interfacesEdit
- Java's Remote Method Invocation (RMI)
- ONC RPC
- XML-RPC or SOAP
- Message Bus (Mbus) (specified in RFC 3259)
- .NET Remoting
Platform communication stackEdit
The following are messaging and information systems that utilize IPC mechanisms, but don't implement IPC themselves:
- KDE's Desktop Communications Protocol (DCOP) – deprecated by D-Bus
- OpenWrt uses ubus micro bus architecture
- MCAPI Multicore Communications API
- SIMPL The Synchronous Interprocess Messaging Project for Linux (SIMPL)
- 9P (Plan 9 Filesystem Protocol)
- Distributed Computing Environment (DCE)
- ZeroC's Internet Communications Engine (ICE)
- Enduro/X Middleware
Operating system communication stackEdit
The following are platform or programming language-specific APIs:
- Apple Computer's Apple events (previously known as Interapplication Communications (IAC)).
- Enea's LINX for Linux (open source) and various DSP and general purpose processors under OSE
- The Mach kernel's Mach Ports
- Microsoft's ActiveX, Component Object Model (COM), Microsoft Transaction Server (COM+), Distributed Component Object Model (DCOM), Dynamic Data Exchange (DDE), Object Linking and Embedding (OLE), anonymous pipes, named pipes, Local Procedure Call, MailSlots, Message loop, MSRPC, .NET Remoting, and Windows Communication Foundation (WCF)
- Novell's SPX
- POSIX mmap, message queues, semaphores, and shared memory
- RISC OS's messages
- Solaris Doors
- System V's message queues, semaphores, and shared memory
- OpenBinder Open binder
- QNX's PPS (Persistent Publish/Subscribe) service
Distributed object modelsEdit
The following are platform or programming language specific-APIs that use IPC, but do not themselves implement it:
- "Interprocess Communications". Microsoft.
- "Windows/WSL Interop with AF_UNIX". Microsoft Corporation. Retrieved 25 May 2018.
- Concurrent programming - communication between processes http://www.tldp.org/pub/Linux/docs/ldp-archived/linuxfocus/English/Archives/lf-2003_01-0281.pdf
- Stevens, Richard. UNIX Network Programming, Volume 2, Second Edition: Interprocess Communications. Prentice Hall, 1999. ISBN 0-13-081081-9
- U. Ramachandran, M. Solomon, M. Vernon Hardware support for interprocess communication Proceedings of the 14th annual international symposium on Computer architecture. Pittsburgh, Pennsylvania, United States. Pages: 178 - 188. Year of Publication: 1987 ISBN 0-8186-0776-9
- Crovella, M. Bianchini, R. LeBlanc, T. Markatos, E. Wisniewski, R. Using communication-to-computation ratio in parallel program designand performance prediction 1–4 December 1992. pp. 238–245 ISBN 0-8186-3200-3