时间戳

首页 > 解决方案 > QuickFIX - 接收和发送来自不同算法的订单（来源）

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

问题描述

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

为了获取和发送由多种算法创建的订单，我有一个 Directory Watcher (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）创建一个新的 web 应用程序来创建一个 REST API（ii）通过 API 接收订单信息，（iii）找到当前的活动会话和（iv ) 使用当前会话向代理服务器发送订单。不幸的是，在运行 FIX 应用程序的不同类上，我无法通过 ID 找到当前会话：

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

我想听你的：

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

谢谢

标签： javarestquickfixfix-protocolalgorithmic-trading

解决方案

Q : What do you think that is the best solution to send FIX orders created by multiple sources?

Definitely the 4) -i.e.- consolidate your multiple sources of decisions and interface the Broker-side FIX Protocol Gateway from a single point.

Reasons:
- isolation of concerns in design/implementation/operations
- single point of authentication/latency-motivated colocation for FIX Protocol channel
- minimised costs of FIX Protocol Gateway acceptance-testing (without this Tier-1 market participants will not let you run business with, so expenses on FIX Protocol E2E-mutual-cooperation compliance-testing do matter - both costs-wise and time-wise )

Q : what are the steps that I can follow?

Follow you own use-case, that defines all the MVP-features that need to be ready for going into testing.

Do not try to generalise your needs into any "new-Next-Gen-API", your trading is all about latency+trading, so rather specialise on the MVP-definition and do not design/implement anything beyond an MVP with minimum latency (overhead) on a point to point basis. Using stable professional frameworks, like nanomsg or ZeroMQ, may avoid spending a bit of time on reinventing any already invented wheels for low-latency trading messaging/signaling tools. Using REST is rather an anti-pattern in the 3rd millenium low-latency motivated high performance distributed computing eco-system for trading.

推荐阅读