如果使用過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作資料欄切格, 要解開FAST需要有對應的template來依序解釋, IB也是一樣, 可直接看它對應的程式碼作了哪些DECODE_FIELD,就好像是template的說明 (可參考IB所提供的程式碼, 舊版可以看 EClientSocketBaseImpl.h 這檔案, 新版則要看 EDecoder.cpp 與 EDecoder.h)  這個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個欄而已  之後參考一下官方的程式碼,很容易就能feed行情了 (tickerId 就是前面的 id 789) 首先是msg id TICK_PRICE所需要的內容   因此設計上可以只用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這樣的開放架構私接訊號當來源, 所以有一個早期經常性的現象, 就是外期很容易三不五時就會錯價, 經過前面的說明, 應該就會瞭解為何會錯價了吧! 不過現在使用路透的資訊源有比較普遍一點, 相對的錯價的情形就少了~ |
|
|