比较 Unix/Linux IPC [英] Comparing Unix/Linux IPC
问题描述
Unix/Linux 提供了许多 IPC:管道、套接字、共享内存、dbus、消息队列...
Lots of IPCs are offered by Unix/Linux: pipes, sockets, shared memory, dbus, message-queues...
最适合每种应用的应用是什么?它们的性能如何?
What are the most suitable applications for each, and how do they perform?
推荐答案
Unix IPC
这里是七大:
仅在与父/子相关的进程中有用.调用 pipe(2) 和 fork(2).单向.
Useful only among processes related as parent/child. Call pipe(2) and fork(2). Unidirectional.
FIFO，或命名管道
与普通管道不同，两个不相关的进程可以使用 FIFO.调用 mkfifo(3).单向.
Two unrelated processes can use FIFO unlike plain pipe. Call mkfifo(3). Unidirectional.
双向.用于网络通信，但也可以在本地使用.可用于不同的协议.TCP 没有消息边界.调用 socket(2).
Bidirectional. Meant for network communication, but can be used locally too. Can be used for different protocol. There's no message boundary for TCP. Call socket(2).
操作系统维护离散消息.请参阅 sys/msg.h.
OS maintains discrete message. See sys/msg.h.
Signal 向另一个进程发送一个整数.不适合多线程.调用 kill(2).
Signal sends an integer to another process. Doesn't mesh well with multi-threads. Call kill(2).
多进程或多线程的同步机制，类似于排队等候上厕所的人.请参阅 sys/sem.h.
A synchronization mechanism for multi processes or threads, similar to a queue of people waiting for bathroom. See sys/sem.h.
做你自己的并发控制.调用 shmget(2).
Do your own concurrency control. Call shmget(2).
消息边界问题
选择一种方法而不是另一种方法时的一个决定因素是消息边界问题.您可能希望消息"彼此分离，但它不适用于像 TCP 或 Pipe 这样的字节流.
Message Boundary issue
One determining factor when choosing one method over the other is the message boundary issue. You may expect "messages" to be discrete from each other, but it's not for byte streams like TCP or Pipe.
考虑一对 echo 客户端和服务器.客户端发送字符串，服务器接收它并立即将其发送回来.假设客户端发送Hello"、Hello"和How about a answer?".
Consider a pair of echo client and server. The client sends string, the server receives it and sends it right back. Suppose the client sends "Hello", "Hello", and "How about an answer?".
使用字节流协议，服务器可以接收Hell"、oHelloHow"和about an answer?"；或者更实际的HelloHelloHow about a answer?".服务器不知道消息边界在哪里.
With byte stream protocols, the server can receive as "Hell", "oHelloHow", and " about an answer?"; or more realistically "HelloHelloHow about an answer?". The server has no clue where the message boundary is.
一个古老的技巧是将消息长度限制为 CHAR_MAX 或 UINT_MAX 并同意在 char 或 中首先发送消息长度代码>uint.因此，如果您在接收方，则必须先读取消息长度.这也意味着一次只能有一个线程读取消息.
An age old trick is to limit the message length to CHAR_MAX or UINT_MAX and agree to send the message length first in char or uint. So, if you are at the receiving side, you have to read the message length first. This also implies that only one thread should be doing the message reading at a time.
对于像 UDP 或消息队列这样的离散协议，您不必担心这个问题，但以编程方式处理字节流更容易，因为它们的行为类似于文件和标准输入/输出.
With discrete protocols like UDP or message queues, you don't have to worry about this issue, but programmatically byte streams are easier to deal with because they behave like files and stdin/out.
这篇关于比较 Unix/Linux IPC的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
