比较 Unix/Linux IPC

问题描述：

Unix/Linux 提供了很多 IPC：管道、套接字、共享内存、dbus、消息队列……

每种最适合的应用程序是什么，以及它们的性能如何？

解决方案 1：

Unix进程间通信

以下是七大因素：

1. 管道

仅在父/子相关进程之间有用。调用pipe(2)和fork(2)。单向。

1. FIFO，即命名管道

与普通管道不同，两个不相关的进程可以使用 FIFO。调用mkfifo(3)。单向。

1. 套接字和Unix 域套接字

双向。用于网络通信，但也可以在本地使用。可用于不同的协议。TCP 没有消息边界。调用socket(2)。

1. 消息队列

OS 维护离散消息。请参阅sys/msg.h。

1. 信号

信号将一个整数发送到另一个进程。与多线程配合不佳。调用kill(2)。

1. 信号

多进程或线程的同步机制，类似于排队等待上厕所的人。请参阅sys/sem.h。

1. 共享内存

进行自己的并发控制。调用shmget(2)。

消息边界问题

选择一种方法而不是另一种方法时，一个决定性因素是消息边界问题。您可能希望“消息”彼此分离，但对于 TCP 或 Pipe 等字节流来说并非如此。

考虑一对回显客户端和服务器。客户端发送字符串，服务器接收并立即返回。假设客户端发送“Hello”、“Hello”和“How about an answer?”。

使用字节流协议，服务器可以接收“Hell”、“oHelloHow”和“关于答案？”；或者更现实地说“HelloHelloHow 关于答案？”。服务器不知道消息边界在哪里。

一个古老的技巧是将消息长度限制为CHAR_MAX或，并同意在或UINT_MAX中首先发送消息长度。因此，如果您在接收方，则必须先读取消息长度。这也意味着一次只能有一个线程执行消息读取。char`uint`

使用像 UDP 或消息队列这样的离散协议，您不必担心这个问题，但以编程方式处理字节流更容易，因为它们的行为类似于文件和标准输入/输出。

解决方案 2：

共享内存可能是最高效的，因为您可以在其上构建自己的通信方案，但它需要很多关注和同步。也有解决方案可用于将共享内存分发到其他机器。

套接字是目前最便携的，但需要比管道更多的开销。能够在本地或通过网络透明地使用套接字是一项很大的优势。

消息队列和信号非常适合硬实时应用程序，但它们不太灵活。

这些方法自然是为了进程之间的通信而创建的，而在进程内使用多个线程可能会使事情复杂化——尤其是信号。

解决方案 3：

这是一个带有简单基准的网页：https：//sites.google.com/site/rikkus/sysv-ipc-vs-unix-pipes-vs-unix-sockets

据我所知，每种方法都有其优点：

• 管道 I/O 速度最快，但需要父/子关系才能工作。

• Sysv IPC 具有定义的消息边界，并且可以本地连接不同的进程。

• UNIX 套接字可以在本地连接不同的进程，并且具有更高的带宽，但没有固有的消息边界。

• TCP/IP 套接字可以连接任何进程，甚至通过网络，但开销较高且没有固有的消息边界。

解决方案 4：

值得注意的是，许多库都在一种类型的东西之上实现了另一种类型的东西。

共享内存不需要使用可怕的 sysv 共享内存函数 - 使用 mmap() 更为优雅（如果您希望命名文件，则 mmap 到 tmpfs /dev/shm 上；如果您希望分叉而非执行的进程匿名继承它，则 mmap /dev/zero）。话虽如此，它仍然需要您的进程进行同步以避免出现问题 - 通常通过使用其他 IPC 机制来同步对共享内存区域的访问。