Jump to content

Inter-process communication: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Fixed typo
Tags: Reverted Visual edit Mobile edit Mobile web edit
Reverted to previous edit due to unexplained content removal by 2406:e003:1197:7701:d810:2ef2:870:be8b
Line 1: Line 1:
{{Short description|How computer operating systems enable data sharing}}
{{Short description|How computer operating systems enable data sharing}}
{{Other uses|IPC (disambiguation){{!}}IPC}}
{{more footnotes|date=August 2015}}
{{more footnotes|date=August 2015}}
[[File:ArchitectureCloudLinksSameSite.png|thumb|upright=1.2|A grid computing system that connects many personal computers over the Internet via inter-process network communication]]
[[File:ArchitectureCloudLinksSameSite.png|thumb|upright=1.2|A [[grid computing]] system that connects many personal computers over the Internet via inter-process network communication]]


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.
In [[computer science]], '''inter-process communication''' or '''interprocess communication''' ('''IPC''') refers specifically to the mechanisms an [[operating system]] provides to allow the [[Process (computing)|processes]] to manage shared data. Typically, applications can use IPC, categorized as [[client–server model|clients and servers]], where the client requests data and the server responds to client requests.<ref name="microsoft.com">{{cite web|url=http://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx| title= Interprocess Communications|publisher=Microsoft}}</ref> Many applications are both clients and servers, as commonly seen in [[distributed computing]].


IPC is very important to the design process for microkernels and nanokernels, which reduce the number of functionalities provided by the kernel. Those functionalities are then obtained by communicating with servers via IPC, leading to a large increase in communication when compared to a regular monolithic kernel. IPC interfaces generally encompass variable analytic framework structures. These processes ensure compatibility between the multi-vector protocols upon which IPC models rely.
IPC is very important to the design process for [[microkernel]]s and [[nanokernel]]s, which reduce the number of functionalities provided by the kernel. Those functionalities are then obtained by communicating with servers via IPC, leading to a large increase in communication when compared to a regular monolithic kernel. IPC interfaces generally encompass variable analytic framework structures. These processes ensure compatibility between the multi-vector protocols upon which IPC models rely.<ref>{{cite journal |last1= Camurati |first1=P |title=Inter-process communications for system-level design |journal= International Workshop on Hardware/Software Codesign |date=1993}}</ref>


An IPC mechanism is either synchronous or asynchronous. Synchronization primitives may be used to have synchronous behavior with an asynchronous IPC mechanism.
An IPC mechanism is either [[Synchronization (computer science)|synchronous]] or asynchronous. [[Synchronization (computer science)#Implementation of Synchronization|Synchronization primitives]] may be used to have synchronous behavior with an asynchronous IPC mechanism.


== Approaches ==
== Approaches ==
Different approaches to IPC have been tailored to different software requirements, such as performance, modularity, and system circumstances such as network bandwidth and latency.
Different approaches to IPC have been tailored to different [[software requirements]], such as [[Algorithmic efficiency|performance]], [[Software design|modularity]], and system circumstances such as [[Bandwidth (computing)|network bandwidth]] and [[Latency (engineering)|latency]].<ref name="microsoft.com"/>


{| class="wikitable"
{| class="wikitable"
! Method !! Short Description !! Provided by ([[operating system]]s or other environments)
|-
| [[computer file|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 form of IPC in the late-1960s that most closely resembles [[Plan 9 from Bell Labs|Plan 9]]'s [[9P (protocol)|9P protocol]]||[[Dartmouth Time-Sharing System]]
|-
| [[signal (computing)|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
|-
| [[network socket|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 ([[Transmission Control Protocol|TCP]]; data written through a socket requires formatting to preserve message boundaries) or more rarely message-oriented ([[User Datagram Protocol|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<ref>{{cite web|title=Windows/WSL Interop with AF_UNIX|date=7 February 2018 |url=https://blogs.msdn.microsoft.com/commandline/2018/02/07/windowswsl-interop-with-af_unix |publisher=Microsoft |access-date=25 May 2018}}</ref>
|-
| [[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
|-
|[[Anonymous pipe]]|| A unidirectional data channel using [[Stdin|standard input and output]]. 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 communication between processes can be achieved by using two pipes in opposite "directions". || All [[POSIX]] systems, Windows
|-
| [[Named pipe]] || A pipe that is treated like a file. Instead of using standard input and output as with an anonymous pipe, processes write to and read from a named pipe, as if it were a regular file. || All POSIX systems, Windows, AmigaOS 2.0+
|-
| [[Shared memory (interprocess communication)|Shared memory]] || Multiple processes are given access to the same block of [[Memory (computing)|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 [[Local Inter-Process Communication|LPC]], [[Remote procedure call|RPC]], [[Remote method invocation|RMI]], and [[Message Passing Interface|MPI]] paradigms, [[Java RMI]], [[CORBA]], [[Component Object Model|COM]], [[Data Distribution Service|DDS]], [[Microsoft Message Queuing|MSMQ]], [[MailSlot]]s, [[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 (computing)|file]]. || All POSIX systems, Windows
|-
|-
|}
|}
Line 20: Line 44:


=== Remote procedure call interfaces ===
=== Remote procedure call interfaces ===
{{main|remote procedure call}}
* Java's Remote Method Invocation (RMI)

* ONC RPC
* [[Java (programming language)|Java]]'s [[Java remote method invocation|Remote Method Invocation]] (RMI)
* XML-RPC or SOAP
* JSON-RPC
* [[ONC RPC]]
* [[XML-RPC]] or [[SOAP (protocol)|SOAP]]
* Message Bus (Mbus) (specified in <nowiki>RFC 3259</nowiki>) (not to be confused with M-Bus)
* [[JSON-RPC]]
* .NET Remoting
* {{anchor|RFC 3259}}Message Bus (Mbus) (specified in RFC 3259) (not to be confused with [[M-Bus (EN 13757)|M-Bus]])
*gRPC
* [[.NET Remoting]]
*[[gRPC]]


=== Platform communication stack ===
=== Platform communication stack ===
The following are messaging, and information systems that utilize IPC mechanisms but don't implement IPC themselves:
The following are messaging, and information systems that utilize IPC mechanisms but don't implement IPC themselves:

{{Div col|colwidth=30em}}
* [[KDE]]'s [[Desktop communication protocol|Desktop Communications Protocol]] (DCOP){{snd}} deprecated by D-Bus
* [[D-Bus]]
* [[OpenWrt]] uses [https://openwrt.org/docs/techref/ubus ubus] micro bus architecture
* [[MCAPI]] Multicore Communications API
* [[SIMPL]] The Synchronous Interprocess Messaging Project for [[Linux]] (SIMPL)
* [[9P (protocol)|9P]] (Plan&nbsp;9 Filesystem Protocol)
* [[Distributed Computing Environment]] (DCE)
* [[Thrift (protocol)|Thrift]]
* [[ZeroC]]'s [[Internet Communications Engine]] (ICE)
* [[ØMQ]]
* [[Enduro/X]] Middleware
* [http://www.inspirel.com/yami4 YAMI4]
* [[Enlightenment_(software)]] E16 uses eesh as an IPC
{{div col end}}


=== Operating system communication stack ===
=== Operating system communication stack ===
The following are platform or programming language-specific APIs:
The following are platform or programming language-specific APIs:
{{Div col|colwidth=30em}}
* [[Apple Computer]]'s [[Apple events]], previously known as Interapplication Communications (IAC)
* [[ARexx]] ports
* [[ENEA AB|Enea's]] [[LINX (IPC)|LINX]] for Linux (open source) and various DSP and general-purpose processors under [[Operating System Embedded|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 pipe#Microsoft Windows|anonymous pipes]], [[Named pipe#Named pipes in Windows|named pipes]], [[Local Procedure Call]], [[MailSlot]]s, [[Message loop in Microsoft Windows|Message loop]], [[MSRPC]], [[.NET Remoting]], and [[Windows Communication Foundation]] (WCF)
* [[Novell]]'s [[IPX/SPX|SPX]]
* [[POSIX]] [[mmap]], [[message queue]]s, [[semaphore (programming)|semaphores]],<ref>"[http://www.tldp.org/pub/Linux/docs/ldp-archived/linuxfocus/English/Archives/lf-2003_01-0281.pdf Concurrent programming - communication between processes]"</ref> and [[Shared memory (interprocess communication)|shared memory]]
* [[RISC OS]]'s messages
* [[Solaris (operating system)|Solaris]] [[Doors (computing)|Doors]]
* [[System V]]'s message queues, semaphores, and shared memory
* [[Transparent Inter-process Communication|Linux Transparent Inter Process Communication (TIPC)]]
* [[OpenBinder]] Open binder
* [[QNX]]'s PPS (Persistent Publish/Subscribe) service
{{div col end}}

=== Distributed object models ===
=== Distributed object models ===
The following are platform or programming language specific-APIs that use IPC, but do not themselves implement it:
The following are platform or programming language specific-APIs that use IPC, but do not themselves implement it:

Revision as of 17:37, 19 July 2022

A grid computing system that connects many personal computers over the Internet via inter-process network communication

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.[1] Many applications are both clients and servers, as commonly seen in distributed computing.

IPC is very important to the design process for microkernels and nanokernels, which reduce the number of functionalities provided by the kernel. Those functionalities are then obtained by communicating with servers via IPC, leading to a large increase in communication when compared to a regular monolithic kernel. IPC interfaces generally encompass variable analytic framework structures. These processes ensure compatibility between the multi-vector protocols upon which IPC models rely.[2]

An IPC mechanism is either synchronous or asynchronous. Synchronization primitives may be used to have synchronous behavior with an asynchronous IPC mechanism.

Approaches

Different approaches to IPC have been tailored to different software requirements, such as performance, modularity, and system circumstances such as network bandwidth and latency.[1]

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 form of IPC in the late-1960s that most closely resembles 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[3]
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
Anonymous pipe A unidirectional data channel using standard input and output. 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 communication between processes can be achieved by using two pipes in opposite "directions". All POSIX systems, Windows
Named pipe A pipe that is treated like a file. Instead of using standard input and output as with an anonymous pipe, processes write to and read from a named pipe, as if it were a regular file. 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 LPC, RPC, RMI, and MPI paradigms, Java RMI, CORBA, COM, 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

Applications

Remote procedure call interfaces

Platform communication stack

The following are messaging, and information systems that utilize IPC mechanisms but don't implement IPC themselves:

Operating system communication stack

The following are platform or programming language-specific APIs:

Distributed object models

The following are platform or programming language specific-APIs that use IPC, but do not themselves implement it:

See also

References

  1. ^ a b "Interprocess Communications". Microsoft.
  2. ^ Camurati, P (1993). "Inter-process communications for system-level design". International Workshop on Hardware/Software Codesign.
  3. ^ "Windows/WSL Interop with AF_UNIX". Microsoft. 7 February 2018. Retrieved 25 May 2018.
  4. ^ "Concurrent programming - communication between processes"
  5. ^ "IpcMain | Electron".