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
Because you construct your own communication mechanism on top of shared memory, it can be the most efficient, but it requires a lot of care and synchronization. There are additional solutions for distributing shared memory to different machines.
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.
These methods were designed to communicate across processes, and employing several threads within a process might make things more complicated, especially when dealing 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.
It’s far 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) for shared memory instead of the terrible sysv shared memory routines. Having said that, your processes will still require some synchronization to avoid difficulties, which can be accomplished by using some of the other IPC protocols to synchronize access to a shared memory space.
Answered by MarkR
Post is based on https://stackoverflow.com/questions/404604/comparing-unix-linux-ipc