使用哪种 Linux IPC 技术？

问题描述：

我们的项目仍处于设计阶段，但我们正在考虑在嵌入式 Linux 内核上设置三个独立的进程。其中一个进程是通信模块，它处理通过各种媒介与设备进行的所有通信。

其他两个进程需要能够通过通信进程发送/接收消息。我正在尝试评估 Linux 提供的 IPC 技术；其他进程将发送的消息大小各不相同，从调试日志到速率约为 5 Mbit 的流媒体。此外，媒体可以同时流入和流出。

您建议该应用程序使用哪种 IPC 技术？
http://en.wikipedia.org/wiki/Inter-process_communication

处理器运行速度约为 400-500 Mhz（如果有任何变化）。不需要跨平台，Linux 即可。需要用 C 或 C++ 实现。

解决方案 1：

当选择 IPC 时，您应该考虑导致性能差异的原因，包括传输缓冲区大小、数据传输机制、内存分配方案、锁定机制实现，甚至代码复杂性。

在可用的 IPC 机制中，性能选择通常归结为Unix 域套接字或命名管道 (FIFO)。我读过一篇关于进程间通信各种机制性能分析的论文，该论文指出，用于 ​​IPC 的 Unix 域套接字可能提供最佳性能。我在其他地方看到过相互矛盾的结果，这些结果表明管道可能更好。

当发送少量数据时，我更喜欢使用命名管道 (FIFO)，因为它们很简单。这需要一对命名管道来进行双向通信。Unix 域套接字需要更多的开销来设置（套接字创建、初始化和连接），但更灵活，并且可能提供更好的性能（更高的吞吐量）。

您可能需要针对您的特定应用程序/环境运行一些基准测试，以确定哪种方法最适合您。根据提供的描述，Unix 域套接字似乎是最合适的。

Beej 的 Unix IPC 指南非常适合开始使用 Linux/Unix IPC。

解决方案 2：

我会选择 Unix 域套接字：比 IP 套接字的开销更少（即没有机器间通信），但其他方面同样方便。

解决方案 3：

难以置信没有人提到 dbus。

http://www.freedesktop.org/wiki/Software/dbus

http://en.wikipedia.org/wiki/D-Bus

如果您的应用程序架构简单，那么可能会有点夸张，在这种情况下 - 在性能至关重要的受控嵌入式环境中 - 您无法击败共享内存。

解决方案 4：

如果性能确实成为一个问题，您可以使用共享内存 - 但它比其他方法复杂得多 - 您需要一个信号机制来发出信号表明数据已准备就绪（信号量等）以及锁以防止在修改结构时对其进行并发访问。

好处是你可以传输大量数据而不必将其复制到内存中，这在某些情况下肯定会提高性能。

也许有一些可用的库可以通过共享内存提供更高级别的原语。

共享内存通常是通过使用 MAP_SHARED 对同一个文件进行映射而获得的（如果不希望其持久化，则可以将其放在 tmpfs 上）；许多应用程序也使用 System V 共享内存（恕我直言，这是出于愚蠢的历史原因；对于同一个东西来说，它的接口不太好）

解决方案 5：

截至撰写本文时（2014 年 11 月），Kdbus 和 Binder 已离开 Linux 内核的暂存分支。目前还不能保证它们是否会成功，但前景都比较乐观。Binder 是 Android 中的轻量级 IPC 机制，Kdbus 是内核中类似 dbus 的 IPC 机制，可减少上下文切换，从而大大加快消息传递速度。

还有“透明进程间通信”或 TIPC，它非常强大，对于集群和多节点设置很有用；http://tipc.sourceforge.net/

解决方案 6：

Unix 域套接字将满足您的大部分 IPC 需求。在这种情况下，您实际上不需要专用的通信过程，因为内核提供了此 IPC 功能。另外，看看 POSIX 消息队列，在我看来，它是 Linux 中利用率最低的 IPC 之一，但在需要 n:1 通信的许多情况下非常方便。