QuickFIX - 接收和发送来自不同算法的订单（来源）

Question

我使用 QuickFIX/J 库构建了一个 FIX Initiator 应用程序来向我的经纪人发送订单。如果您不知道什么是 FIX 应用程序，请考虑我的程序是一个通过 TCP 连接向服务器发送消息的应用程序。

为了获取和发送由多种算法创建的订单，我有一个目录观察器 (WatchService)，它使用 AWS Cli 监视与 S3 存储桶同步的本地目录上的修改。

这种方法效果很好，除了我必须等待大约 6-8 秒才能将文件放入我的本地目录，这样我可以解析它以修复订单并发送到经纪人的 FIX 应用程序。我真的很想减少订单创建和订单发送给经纪人之间的延迟。

我认为有哪些可能的解决方案：

1) 不使用 AWS CLI 直接从 S3 存储桶读取

2） 针对每个不同的算法开启不同的FIX会话

3) 不是从桶中读取数据，而是为新订单访问数据库 (MySQL)。算法将生成表格行而不是文件

4) 在我的 FIX 应用程序和算法之间有一个 API，所以算法可以直接连接到我的应用程序。

解决方案 (1) 没有改进订单接收时间，因为列出 S3 对象、获取摘要和过滤所需文件所花费的时间大致相同。

解决方案（2）我没有尝试过，但我认为这不是最好的。例如，如果我有 100 种不同的策略，我将不得不打开 100 个不同的连接，而且我不确定我的代理应用程序是否可以处理。但我可能错了。

解决方案（3）我也没试过。

解决方案（4）是我认为理想的，但我不知道如何实施。我试图创建一个 REST API，但我不知道它在概念上是否正确。假设我的 FIX 应用程序当前连接到经纪人的服务器，我的想法是 (i) 创建一个新的 webapp 来创建一个 REST API (ii) 通过 API 接收订单信息，(iii) 找到当前活动会话和 (iv ) 使用当前会话向代理服务器发送订单。不幸的是，我无法通过 ID 在运行 FIX 应用程序的不同类上使用以下内容找到当前会话：

SessionID sessionID = new SessionID("FIX.4.4", "CLIENT1", "FixServer"); 
   Session session = Session.lookupSession(sessionID);

我想听听您的意见：

• 您认为发送由多个来源创建的 FIX 订单的最佳解决方案是什么？

• 如果我想创建一个 API 来连接 2 个不同的应用程序，我可以遵循哪些步骤？

如果我有点困惑，我很抱歉。如果您需要进一步说明，请告诉我。

Answer 1

问：您认为发送由多个来源创建的 FIX 订单的最佳解决方案是什么？绝对是4) - 即 - 整合您的多个决策来源，并从一个点连接代理方 FIX 协议网关。原因：- 隔离设计/实施/操作中的关注点- FIX 协议通道的单点身份验证/延迟驱动的托管- 最小化 FIX 协议网关验收测试的成本（没有这个，一级市场参与者不会让你经营业务有，因此 FIX 协议 E2E 相互合作合规性测试的费用很重要 - 无论是成本方面还是时间方面）问：我可以遵循哪些步骤？遵循您自己的用例，它定义了所有需要准备好进行测试的 MVP 功能。不要试图将您的需求概括为任何“新的下一代 API”，您的交易完全是关于延迟+交易，所以更专注于 MVP 定义并且不要设计/实现任何超出最小延迟的 MVP（开销）在点对点的基础上。使用稳定的专业框架，如nanomsg或ZeroMQ，可以避免花费一些时间重新发明任何已经发明的低延迟交易消息/信号工具的轮子。在第三个千年的低延迟驱动的高性能分布式交易计算生态系统中，使用 REST 是一种反模式。