Problem
Unix/Linux has a wide range of IPCs, including pipes, sockets, shared memory, dbus, message queues, and so on.
What are the best applications for each, and how well do they work?
Asked by user27424
Solution #1
The big seven are as follows:
The message boundary issue is one deciding element for choosing one approach over the other. Although you might anticipate “messages” to be distinct from one another, this is not the case with byte streams like TCP or Pipe.
Consider an echo client and server pair. The client transmits a string, which the server receives and sends back to the client. Let’s say the client sends three messages: “Hello,” “Hello,” and “How about an answer?”
The server can receive messages such as “Hell,” “oHelloHow,” and “about an answer?” via byte stream protocols, or more realistically, “HelloHelloHow about an answer?” The message boundary is unknown to the server.
Limiting the message length to CHAR MAX or UINT MAX and agreeing to send the message length first in char or uint is an old method. As a result, if you are on the receiving end, you must first read the message length. This also suggests that the message reading should be done by only one thread at a time.
You don’t have to worry about this with discrete protocols like UDP or message queues, but byte streams are easier to deal with programmatically because they behave like files and stdin/out.
Answered by 8 revs, 2 users 85%
Solution #2
Shared memory can be the most efficient since you build your own communication scheme on top of it, but it requires a lot of care and synchronization. Solutions are available for distributing shared memory to other machines too.
These days, sockets are the most portable, but they require more overhead than pipelines. The ability to use sockets transparently locally or over a network is a huge plus.
Message queues and signals are useful for harsh real-time applications, but they lack flexibility.
Thread for process communication, and having many threads within a process can make things more complicated — especially with signals.
Answered by Judge Maygarden
Solution #3
Here’s a link to a webpage with a basic benchmark: https://sites.google.com/site/rikkus/sysv-ipc-vs-unix-pipes-vs-unix-sockets
As far as I can tell, each has its own set of benefits:
Answered by Phillip Whelan
Solution #4
It’s worth noting that lots of libraries implement one type of thing on top of another.
Shared memory doesn’t need to use the horrible sysv shared memory functions – it’s much more elegant to use mmap() (mmap a file in on a tmpfs /dev/shm if you want it named; mmap /dev/zero if you want forked not exec’d processes to inherit it anonymously). Having said that, it still leaves your processes with some need for synchronisation to avoid problems – typically by using some of the other IPC mechanisms to do synchronisation of access to a shared memory area.
Answered by MarkR
Post is based on https://stackoverflow.com/questions/404604/comparing-unix-linux-ipc