交易
FIX（簡單二進制編碼）與專有協議性能和成本的 HFT 增強
我想從那些使用 FIX（使用簡單二進制編碼）進行 HFT 的人那裡知道，與目前使用的（專有）協議相比，這些協議通常因交易對手而異。
對頻寬使用率和開發時間差異感興趣。例如，支持 FIX SBE 的各種 FIX 引擎（有列表嗎？）是否允許軟體團隊使用他們的模型更快地進入市場，而不是必須學習每個專有交易協議？
這是一個非常困惑的問題，OP 顯然在這個行業中不起作用。任何與交易所的連接都需要使用交易所選擇的格式。即，您別無選擇。
也就是說，我不知道有哪個交易所允許通過 SBE 輸入訂單。CME Group 將使用 SBE 為其新的市場數據饋送（取代 FAST 壓縮），但僅此而已。
FIX 有一些已知的缺陷。重複組就是其中之一。解析重複組內的重複組的延遲可能會很昂貴，需要遞歸呼叫。我更喜歡發送第一條消息的協議，表明 N 條消息將跟隨組資訊。
FIX 也太冗長，消耗太多頻寬。為此，他們提出了 FAST，它對 FIX 進行了大量壓縮，但主要由交易所用於市場數據，而不是訂單路由。
當我們開發 FIX 和 FAST 引擎 ( CoralFIX ) 時，我們專注於三件事：
- 它必須有一個非常直覺且易於使用的 API，以便在對與交易所的連接進行編碼時快速周轉。
- 它必須是低延遲，從頭開始設計以提高速度。
- 如果它是 Java 的，它必須留下零垃圾，否則 GC 將增加不可接受的延遲和變異數。
**免責聲明：**我是 CoralFIX 的開發者之一。