Embedded Files
如果使用過fakePATS API, 就會知道雖然架構和PATS一模一樣 但是完全和PATS無關,
而且行情速度與完整性確是截然不同, 並須完全拋開PATS的牛速/漏價/不穩定的感覺,
現在也可以有全新的體驗發生在IB(Interactive Brokers)的應用架構上了!
IB與PATS於GMDS上的設計差異:
於PATS的部分是設計於用戶端替換PATS原本的dll來運行
GMDS <----> fakePATS-API : PATS's API applications
於IB則是設計於Server端開Socket介面走TWS協議運作
GMDS : IB-API-Server <----> IB-API programs
未免有人踩雷浪費時間看下去, 特別再提醒一下:
網路上的討論與應用都是使用IB API去收IB的data或透過IB下單, 如果有Server的字眼是指將IB提供的data重新發行,
這裡所提的是直接換掉雲架構 使所有以IB API開發的任何應用移轉到GMDS架構下運行,
因此透過GMDS能接收任何其他來源的data或配合下單到任意券商
其實IB提供的API與TWS/IBG間的通訊規格很簡單, 就像是FAST使用End-Bit作資料欄切格,
IB則是 ZE-String 以 ZE 作為token, 所以取得msg id後
要解開FAST需要有對應的template來依序解釋, IB也是一樣,
可直接看它對應的程式碼作了哪些DECODE_FIELD,就好像是template的說明
(可參考IB所提供的程式碼, 舊版可以看 EClientSocketBaseImpl.h 這檔案, 新版則要看 EDecoder.cpp 與 EDecoder.h)
圖中第2欄id為3 代表是對應商品 GBP/USD 的資料
這個API說好用是好用,說不好用是真的好難用,其實就是版本與環境問題,
如果不想受限於開發平台也不想裝一堆轉散發套件,那就是自己用Socket寫起來就好了~
而會寫Client,當然Server也是一樣的道理,就不多說了!
IB-API-test.exe為單一隻程式,不用dll不用ocx
只要裝好Windows(Win95/98/XP/2000~Win10)就可以直接用了~程式下載
使用方式(僅供測試,可以改變連線主機,註冊固定的三個免費外匯商品而已)
由以上的測試, 任何能用 IB API 接收行情資料的應用程式,
只要透過GMDS架構都能輕鬆建立對應的服務器提供服務!
<TSHS-UniDbf-TWS> : 適合有自建GMDS行情源 - 券商內部,法人,自營
TSHS-UniDbf-TWS為接收UniDbf/PatsEmu的來源,除提供原本的TSHS服務外,
不但可用於轉譯IB用戶端的的資料接收與行情推播,
同時提供以PES服務方式作為 TSHS-GW-TWS 的資訊源,
可以用為控管用戶權限,商品訂閱等機制...
<TSHS-GW-TWS> : 適合以GMDS為行情源建置客戶端服務所需之雲端架構
TSHS-GW-TWS為透過PES/PEC的通訊規格連接用戶端和雲端
作為 TSHS-UniDbf-TWS 對應於用戶端的 Gateway 服務程式,
用於轉譯並傳遞用戶端要求,同時進行資料接收與推播,
就像是TWS/IBG提供的API服務器供Socket Clients應用
依據用戶端的測試結果,正確模擬TWS運作,
可讓測試用的Client IB-API-test正確上線要求註冊商品
當然也能用官方的Client測試通過
然後觀察註冊行情資料的情形,如果使用GMDS架構大概只需在意其中3個欄而已
ps:兩組#1#2#3只是在數數,並無匹對關係,因為由內容就很容易看出是什麼
之後參考一下官方的程式碼,很容易就能feed行情了 (tickerId 就是前面的 id 789)
首先是msg id
行情的msg id
// incoming msg id's
const int TICK_PRICE = 1;
const int TICK_SIZE = 2;
TICK_PRICE所需要的內容
TICK_SIZE所需要的內容
觀察TICK_SIZE和TICK_PRICE之後,可以瞭解使用TICK_PRICE ver 2 以上的版本其實就能取代TICK_SIZE,
因此設計上可以只用TICK_PRICE,除非如果有價位沒異動想節省通訊量的狀況才須設計TICK_SIZE,
最後模擬一下, 果然測試成功!
回補的部分只要看一下 EDecoder.h 有定義這個訊息 HISTORICAL_DATA ,
就可以於 EDecoder.cpp 找到對應 processHistoricalDataMsg
看吧, 真的很簡單呢!
本來IB推出API的用意應該是想讓用戶們可以和TWS互動更密切,讓用戶對IB更依賴更死忠,
而IB在支持API的方面也一直都非常下工夫, 現在使用GMDS正好反其道而行,
原本透過IB API設計的各種應用或架構全都可以搬到GMDS上直接使用了!
資訊來源更廣更快更穩定, 下單配合券商可以設計更多樣化,
銜接IB API後可以自主開發各種平台利用各種資源...
不過, 很明顯的發現跟PATS來源有相同的缺點, 就是沒有提供交易所來源的時間資料可以用,
但是, 既然Client端的API與目的主機Server都是可自行設計的狀態下,
所以就也可以另外定義更好的通訊規格來應用~
如同CME已改用SBE淘汰FAST, 而SBE使用頻寬的情形約是FAST的2.5倍,
明知有頻寬需求超大的缺陷為何還是要換呢? 只能說因為FAST真的很不好吧!
這邊IB API前面就說到跟FAST很類似, 所以當然有相同的缺點,
最大的問題就是要增刪欄位就要換版, 不然就要另訂格式,
只要版本對不上或是格式對不上時, 資料就會亂了套!
這種規格如果是應用在Multicast/packet的架構上或許比較沒問題,
因為每個封包等同重置可以重新對齊資料的解釋,
但是用在Unicast/stream的架構中只要一亂, 要重新對齊就值得深思了!
有經驗的就會發現, 很多系統中都會有所謂的head/leading-byte
其實就是為了便於解決這種問題, 讓stream可以parser成packet的用法,
很顯然的IB沒有將這個考慮進去, 而事實上很多外期的來源其實也都不是來自交易所,
有更多是類似像IB這樣的開放架構私接訊號當來源, 所以有一個早期經常性的現象,
就是外期很容易三不五時就會錯價, 經過前面的說明, 應該就會瞭解為何會錯價了吧!
不過現在使用路透的資訊源有比較普遍一點, 相對的錯價的情形就少了~
Report abuse