比较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

这是七个大人物:

Unix IPC

Here are the big seven:

1. 管道

仅在与父/子相关的进程中有用.呼叫 pipe(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).

消息队列

OS维护离散消息.参见 sys/msg.h .

OS maintains discrete message. See sys/msg.h.

信号

信号将整数发送到另一个进程.与多线程的配合不佳.呼叫 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.

考虑一对回显客户端和服务器.客户端发送字符串，服务器接收它，然后立即将其发送回去.假设客户端发送"Hello"，"Hello"和答案如何?".

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"和关于答案?"的信息；或者更实际的是"HelloHello答案如何?".服务器不知道消息边界在哪里.

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或消息队列之类的离散协议，您不必担心此问题，但是通过编程方式字节流更易于处理，因为它们的行为类似于文件和stdin/out.

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屋！