在Linux上的进程之间传递消息的最快技术？

Question

在Linux上，在C ++应用程序进程之间发送消息的最快技术是什么？ 我隐约知道桌上有以下技巧：

• TCP协议
• UDP协议
• 插座
• 管子
• 命名管道
• 内存映射文件

还有更多的方法，最快的是什么？

Answer 1

尽管以上所有答案都非常好，但我认为我们必须讨论什么是“最快” [并且它必须是“最快”还是仅仅是“足够快”？

对于大消息，毫无疑问，共享内存是一种非常好的技术，并且在许多方面都非常有用。

但是，如果消息很小，则必须提出自己的消息传递协议和通知其他进程有消息的方法，这是不利的。

在这种情况下，管道和命名管道更容易使用-它们的行为非常类似于文件，您只需在发送方写入数据，然后在接收方读取数据。 如果发送方写东西，则接收方会自动唤醒。 如果管道已满，则发送方将被阻塞。 如果没有更多来自发送方的数据，则接收方将自动被阻止。 这意味着可以用很少的几行代码来实现，并且很好地保证了它每次都可以正常工作。

另一方面，共享内存依赖于某种其他机制来通知另一线程“您有要处理的数据包”。 是的，如果要复制大量数据包，这将非常快-但是，如果管道之间确实存在巨大差异，我会感到惊讶。 主要好处是另一侧不必从共享内存中复制数据-但它也依赖于有足够的内存来容纳所有“运行中”消息，或者发送者有能力阻止某些事情。

我并不是说“不要使用共享内存”，而是说没有诸如“一种解决所有'最佳'问题的解决方案”之类的东西。

需要说明的是：首先，我将使用管道或命名管道（取决于适合的目的）来实现一个简单的方法，并评估其性能。 如果实际花费大量时间来复制数据，那么我会考虑使用其他方法。

当然，另一个考虑应该是“我们是否要使用两台单独的计算机（或同一系统上的两个虚拟机）来解决此问题。在这种情况下，网络解决方案是一个更好的选择-即使它不是最快的，我已经在我的机器上运行了本地TCP堆栈以进行基准测试，并获得了20-30Gbit / s（2-3GB / s）的持续流量，而在同一进程中的原始内存大约为50-100GBit / s （5-10GB / s）（除非块的大小非常小并且适合L1缓存）。我没有测量标准管道，但是我希望它大约在这两个数字的中间。对于许多不同的中型相当现代的PC来说都是正确的-显然，在ARM，MIPS或其他嵌入式样式的控制器上，期望所有这些方法的数量都更少。

Answer 2

我建议您也看一下： 如何在C中使用Linux共享内存 。

基本上，我在一台计算机上进行IPC时会丢弃诸如TCP和UDP之类的网络协议。 这些具有打包开销，并且绑定到甚至更多的资源（例如端口，环回接口）。

Answer 3

英国剑桥大学的NetOS系统研究小组已经完成了一些（开源）IPC基准测试。

源代码位于https://github.com/avsm/ipc-bench 。

项目页面： http : //www.cl.cam.ac.uk/research/srg/netos/projects/ipc-bench/ 。

结果： http : //www.cl.cam.ac.uk/research/srg/netos/projects/ipc-bench/results.html

这项研究已使用上述结果发表： http : //anil.recoil.org/papers/drafts/2012-usenix-ipc-draft1.pdf

Answer 4

检查CMA和kdbus： https ://lwn.net/Articles/466304/

我认为这些天最快的东西是基于AIO。 http://www.kegel.com/c10k.html

Answer 5

当您使用C ++标记此问题时，我建议使用Boost.Interprocess ：

共享内存是最快的进程间通信机制。 操作系统将内存段映射到多个进程的地址空间中，以便多个进程可以在该内存段中进行读写操作，而无需调用操作系统功能。 但是，我们需要在读取和写入共享内存的进程之间进行某种同步。

资源

我发现的一个警告是同步原语的可移植性限制 。 例如，OS X和Windows都不具有进程间条件变量的本地实现，因此它使用自旋锁来模拟它们。

现在，如果使用支持POSIX进程共享原语的* nix，将不会有任何问题。

当涉及大量数据时，通过同步共享内存是一种好方法。

Answer 6

好吧，您可以使用linux共享内存 （也称为SHM在进程之间简单地拥有一个共享内存段。

它很容易使用，请查看一些示例链接。

Answer 7

posix消息队列非常快，但是有一些限制