【发布时间】:2014-06-26 15:57:07
【问题描述】:
我需要使用多个不同的数据以不同的速率更新多个进程,但速度要快至 10 Hz。我不希望接收进程必须主动获取这些数据,而是将其推送给它们,以便他们只需要在实际有新数据时对新数据做任何事情(没有轮询)。
我可能只向每个进程发送几个字节的数据。传输的数据可能不需要永久存储,至少在接收者接收和处理之前不需要。此外,没有数据的更新频率低于每几秒一次,因此接收器崩溃不是问题(一旦崩溃的接收器恢复,它可以等待下一次更新)。
我查看了 unix 域套接字和 UDP 以及一些管道和共享内存,但它们似乎不太适合我想要做的事情:
- 域套接字要求发送方向每个接收方发送单独的消息(即不进行广播/多播)
- 共享内存的缺点是让客户端检查数据是否已更新(除非有一种我不熟悉的机制可以通知他们)
- UDP 不保证消息会到达(可能不是同一台计算机上的通信问题?),我担心网络堆栈的开销(哪些域套接字没有)
对 TCP(以及支持设备间通信的其他协议)的担忧在于,存在单个设备上的进程间通信不需要的功能,这可能会产生不必要的开销。
感谢您对参考资料和资源的任何建议和指导。
【问题讨论】:
-
我可能遗漏了一些东西,我对“太宽泛”的标签有点困惑。 hBrent 涵盖了基本的进程间通信,Maxim 提出了持久的非结构化和结构化共享存储,我还提到了一个消息队列库的例子。在我看来,我们已经涵盖了 hBrent 问题的一般答案空间的很大一部分。或者您可能担心人们会开始从这些一般领域中抽取太多详细示例?还是您过于宽泛的担忧来自其他原因?
-
我在问题被搁置后对其进行了编辑。如果它不符合从搁置状态中删除的要求,请提供一些反馈(尽可能具体)关于我如何使它达到可接受的程度。谢谢。
-
我看到你问的是“如何在 Unix 进程之间传递少量数据?”您已经检查了 Unix IPC 中的常见问题,并从您的角度陈述了它们的不足之处。我想知道“任何关于参考和资源的建议和方向都值得赞赏”的措辞。让人们望而却步。尽管主题领域并不广泛,但最后一个问题可能被认为过于广泛。您如何看待在最后一个问题中非常具体? (顺便说一句,我只是在猜测,我希望高级代表会做出回应。)
-
@DavidPointer,我想你可能是对的。我会看看我是否不能对最后一个问题更具体。我还应该查看帮助中心的规则,以便更好地了解预期内容。我也不知道问题是否在每次编辑时都会得到审核,或者是否有其他原因会触发重新考虑。
标签: linux unix interprocess inter-process-communicat