使用哪种Linux IPC技术？

我们仍然处于项目的devise阶段，但是我们正考虑在embedded式Linux内核上使用三个独立的进程。其中一个过程是一个通信模块，通过各种介质处理与设备之间的所有通信。

其他两个进程将需要能够通过通信过程发送/接收消息。我正在评估Linux提供的IPC技术; 其他进程将发送的消息大小也不相同，从debugging日志到大约5 Mbit速率的stream媒体。而且，媒体可以同时stream入和stream出。

你会为这个应用程序build议哪种IPC技术？ http://en.wikipedia.org/wiki/Inter-process_communication

处理器运行在400-500兆赫左右，如果这改变了一切。不需要跨平台，Linux才行。在C或C ++中的实现是必需的。

我会去的Unix域套接字：比IP套接字（即没有机间通信）更less的开销，但相同的便利，否则。

selectIPC时，应考虑性能差异的原因，包括传输缓冲区大小，数据传输机制，内存分配scheme，locking机制实现，甚至代码复杂性。

在可用的IPC机制中，性能的select通常归结为Unix域套接字或命名pipe道（FIFOs）。我读了一篇关于进程间通信的各种机制的性能分析的论文，指出IPC的Unix域套接字可以提供最好的性能。我看到别处有矛盾的结果表明pipe道可能会更好。

在发送less量数据时，我更喜欢命名pipe道（FIFOs）。这需要一对命名pipe道进行双向通信。 Unix域套接字在安装（套接字创build，初始化和连接）方面需要更多的开销，但是更灵活，可以提供更好的性能（更高的吞吐量）。

您可能需要针对您的特定应用程序/环境运行一些基准testing，以确定哪些最适合您。从提供的描述中，听起来像Unix域套接字可能是最合适的。

Beej的Unix指南IPC适用于Linux / Unix IPC入门。

不敢相信没有人提到dbus。

如果您的应用程序在结构上很简单，那么在性能至关重要的受控embedded式环境中，您可能无法打败共享内存。

如果性能真的成为一个问题，你可以使用共享内存 – 但它比其他方法复杂得多 – 你需要一个信号机制来表示数据已经准备就绪（信号量等）以及locking，以防止并发访问结构而他们正在修改。

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

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

共享内存通常是通过使用MAP_SHARED（如果你不想保存的话可以在tmpfs上）压缩同一个文件来获得的。许多应用程序也使用System V共享内存（恕我直言，愚蠢的历史原因，这是一个不太好的接口，同样的事情）

有关“经典”Linux IPC机制的评论，请看这里。

在撰写本文时（2014年11月），Kdbus和Binder离开了linux内核的升级分支。目前还没有保证要么能够进入，但两者的前景都是有利的。 Binder是Android中的一个轻量级的IPC机制，Kdbus是内核中类似dbus的IPC机制，它减less了上下文切换，从而大大加快了消息传递速度。

还有“透明的进程间通信”或TIPC，这对于群集和多节点设置是强大的，是有用的; http://tipc.sourceforge.net/