为事件驱动的应用程序选择 IPC 解决方案答案

【问题标题】：Choosing a IPC solution for an event-driven application为事件驱动的应用程序选择 IPC 解决方案
【发布时间】：2011-05-20 21:42:54
【问题描述】：

我目前正在开发一个相当大的单线程、基于事件的应用程序，该应用程序围绕 Linux 下的 epoll 和其他平台下的类似技术设计。目前，每当我们希望两个实例进行通信时，它们通常通过套接字进行，无论它们是否在同一台机器上运行。出于性能原因，我设想使用某种形式的 IPC 来加速同一台机器的通信。现在，我需要决定使用哪种 IPC 机制。

以下因素对我很重要：

事件驱动，没有完全重新设计——如果 IPC 机制不能很好地适应 epoll，那我几个月的工作就白费了
快——如果这个机制不比套接字快，那就不值得花时间去实现它
在执行期间灵活且（重新）可配置 -- 我相信这排除了 MPI 和 al
不需要多线程。

我愿意为不同的平台使用不同的机制，只要它们都使用相同的范例。我也愿意深入了解 C/C++/Obj-C 的平台特定绑定。

有什么建议吗？

谢谢。

【问题讨论】：

顺便说一句，socket 在同一台机器上打开时性能要好得多：stackoverflow.com/questions/1644851/…
嗯，根据我的经验，IP 套接字不会。

标签： c ipc epoll iocp kqueue

【解决方案1】：

Unix 套接字。命名管道。先进先出。

这些都提供相同的基本功能 - 相同的机器跨进程通信。不过，这些实现提供的行为略有不同。

它们都使用文件描述符，因此您可以直接将它们插入您的套接字原来所在的位置。

【讨论】：

IIRC，FIFO 是在管道之上实现的，并且管道以不太快而闻名（我已经有好几年没有检查过了，所以我可能不是最新的主题）。
*nix 传统上花费了相当长的时间来优化他们的管道实现。它们并不慢，但属于最快的 IPC 机制。

【解决方案2】：

确实，正如 skwllsp 所提到的，AF_INET 套接字针对本地主机上的数据传输进行了优化，并且速度和复杂性与 fifos、管道、unix 套接字相当（几乎相同？）（如果目的地是同一主机）。我的 2 美分是使用插座。这样，您不仅可以为 IPC 机制保留相同的接口，而且还可以成功地在远程和本地场景中重用您的代码。

【讨论】：

【解决方案3】：

试用 Unix SysV IPC。它支持：-

消息队列
信号量
共享内存

这可能对你有帮助。

此链接可能会有所帮助： http://www.ibm.com/developerworks/aix/library/au-ipc/index.html

【讨论】：

SysV IPC真的兼容epoll方式吗？我的印象是事实并非如此。
我找不到任何不兼容的原因，但老实说我还不确定！那么问题是 SysV IPC 只是另一种类型，只要您设法使用套接字（虽然我不知道您使用的是哪个套接字，但我猜是 TCP）那么它应该不是问题。
让我重新表述一下：epoll 非常面向 fd。 SysV IPC 使用完全事件系统，不是吗？所以我基本上必须从两个来源而不是一个来源进行投票？