使用哪种Linux IPC技术？

我们仍处于项目的设计阶段，但我们正在考虑在嵌入式Linux内核上具有三个独立的进程。进程之一是通信模块，该模块处理通过各种介质往返于设备的所有通信。

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

您将为该应用建议哪种IPC技术？ http://en.wikipedia.org/wiki/进程间通信

如果发生任何变化，处理器的运行速度约为400-500 Mhz。无需跨平台，仅Linux即可。需要使用C或C ++实现。

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

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

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

当发送少量数据时，为简化起见，我更喜欢使用命名管道（FIFO）。这需要一对命名管道进行双向通信。Unix域套接字在设置（套接字创建，初始化和连接）上花费了更多的开销，但是更加灵活，并且可以提供更好的性能（更高的吞吐量）。

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

Beej的Unix IPC指南非常适合Linux / Unix IPC入门。

不能相信没有人提到dbus。

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

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

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

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

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

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

共享内存通常是通过使用MAP_SHARED映射同一文件来获得的（如果您不希望持久化，可以在tmpfs上）；许多应用程序还使用System V共享内存（出于愚蠢的历史原因，恕我直言；对同一件事它的界面要差很多）

在撰写本文时（2014年11月），Kdbus和Binder已离开linux内核的暂存分支。目前尚不能保证两者都能加入，但两者的前景都是乐观的。Binder是Android中的轻量级IPC机制，Kdbus是内核中的类似dbus的IPC机制，它减少了上下文切换，从而大大加快了消息传递速度。

还有“透明的进程间通信”或TIPC，它很健壮，对于群集和多节点设置很有用。http://tipc.sourceforge.net/

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