比较 Unix/Linux IPC
- 2024-10-29 08:35:00
- admin 原创
- 194
问题描述：
Unix/Linux 提供了很多 IPC：管道、套接字、共享内存、dbus、消息队列……
每种最适合的应用程序是什么，以及它们的性能如何？
解决方案 1：
Unix进程间通信
以下是七大因素：
管道
仅在父/子相关进程之间有用。调用pipe(2)和fork(2)。单向。
FIFO，即命名管道
与普通管道不同，两个不相关的进程可以使用 FIFO。调用mkfifo(3)。单向。
套接字和Unix 域套接字
双向。用于网络通信，但也可以在本地使用。可用于不同的协议。TCP 没有消息边界。调用socket(2)。
消息队列
OS 维护离散消息。请参阅sys/msg.h。
信号
信号将一个整数发送到另一个进程。与多线程配合不佳。调用kill(2)。
信号
多进程或线程的同步机制，类似于排队等待上厕所的人。请参阅sys/sem.h。
共享内存
进行自己的并发控制。调用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 机制来同步对共享内存区域的访问。
