QuickFIX-接收和發送來自不同算法的訂單（源）

Question

我使用QuickFIX / J庫構建了一個FIX啟動器應用程序，以將訂單發送給我的經紀人。 如果您不知道什么是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）創建一個新的Web應用程序以創建REST API（ii）通過API接收訂單信息，（iii）查找當前的活動會話，以及（iv ）使用當前會話將訂單發送到代理服務器。 不幸的是，在不同的運行FIX應用程序的類上，我無法使用以下代碼通過ID查找當前會話：

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

我想聽聽您的意見：

• 您認為發送由多個來源創建的FIX訂單的最佳解決方案是什么？

  • 如果我想創建一個連接兩個不同應用程序的API，可以遵循哪些步驟？

很抱歉，如果我有點困惑。 讓我知道您是否需要進一步說明。

謝謝

Answer 1

問 ： 您認為發送多個來源創建的FIX訂單的最佳解決方案是什么？

絕對是4）-即-合並您的多個決策源，並從單一角度連接Broker-side FIX協議網關。

原因：
-隔離設計/實施/操作中的問題
-FIX協議通道的單點身份驗證/等待時間共置
-最小化FIX協議網關驗收測試的成本（沒有這個1級市場參與者將不允許您開展業務，因此FIX協議E2E相互合作合規性測試的費用很重要-無論是在成本方面還是在時間方面）

問 ： 我可以遵循哪些步驟？

遵循您自己的用例，該用例定義了需要准備好進行測試的所有MVP功能。

不要嘗試將您的需求概括為任何“新的下一代API”，您的交易全都是關於延遲+交易的，所以請專注於MVP定義，不要以最小的延遲設計/實現MVP以外的任何東西（點對點）。 使用穩定的專業框架（例如nanomsg或ZeroMQ ）可以避免花一些時間重新發明任何已經發明的用於低延遲交易消息/信號傳遞工具的工具。 在第3千年低延遲動機的高性能分布式計算生態系統中，使用REST是一種反模式。