QuickFix 使用管道、共享内存、消息队列等答案

【问题标题】：QuickFix using Pipes, shared memory, message queues etcQuickFix 使用管道、共享内存、消息队列等
【发布时间】：2013-01-29 05:03:14
【问题描述】：

这是我的场景：在我的应用程序中，我有几个使用内部使用 tcp 套接字的 Quickfix 相互通信的进程。流程如下：

进程1发送quickfix消息->进程2在处理来自的消息后发送quickfix消息进程 1 -> .....->进程 n

确认消息的流程类似，

进程 n->....->进程 1

现在，除了最后一个进程（进程 n）之外的所有这些进程都在同一台机器上。我google了一下，发现tcp套接字是ipc机制中最慢的。

那么，有没有办法传输和接收快速修复消息（显然使用他们的 api）通过其他 IPC 机制。如果是，我可以通过在同一台机器上的所有进程之间使用该 ipc 机制来减少延迟。

但是，如果我这样做，这些机制是否能像 tcp 套接字那样保证完整消息的传输？

【问题讨论】：

TCP 套接字不保证完整消息的传输。它们保证字节流的传输。因此，您的问题毫无意义。
@EJP：主要原因不是“保证完整消息的传输”而是速度
所以澄清你的问题。此刻它仍然毫无意义。除了询问是否存在其他 IPC 系统（答案显然是“是”）之外，您根本没有问任何问题，除了其他 IPC 系统是否与 TCP 共享 TCP 甚至没有的属性。
tcp 套接字是最慢的 ipc 机制 谁说的？？通过网络，您需要套接字或在下面使用套接字的系统。你无法逃脱它。

标签： networking tcp quickfix

【解决方案1】：

我认为你正在做过早的优化，我认为 TCP 不会成为你的性能瓶颈。您的本地 LAN 延迟将比您的外部 FIX 连接更快。根据经验，我认为性能问题源于您应用的消息处理（可能是由于 OnMessage() 回调中的意外阻塞），而不是随后发生的 IPC 问题。

建议： 使用抽象层接口编写您的通信组件，以便稍后您可以将 TCP 换成其他东西（例如 ActiveMQ、ZeroMQ 或您可能考虑的其他东西），如果您决定你可能需要它。

除此之外，只需专注于使您的系统正常工作即可。一旦你确定行为是正确的（希望通过测试来确认它们），那么你就可以提高性能了。 在进行任何优化之前衡量您的表现，然后在您进行“改进”后再次衡量。不要相信你的直觉；获取数字。

【讨论】：

【解决方案2】：

虽然很高兴听到有关与此问题相关的要求的更多详细信息，但我建议查看共享内存解决方案。我假设您正在使用交易匹配引擎在托管设施中运行服务器，并使用高速、内核绕过通信进行外部通信。 TCP 的问题之一是用户/内核空间转换。我建议考虑 IPC 的用户空间共享内存，并使用繁忙的轮询技术进行同步，而不是使用可能还涉及内核转换的同步机制。

【讨论】：