輕量級STEP會話層接口規(guī)范VIP

1、Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28I輕量級輕量級 STEPSTEP 會話層接口規(guī)范會話層接口規(guī)范（LFIXTLFIXT 會話協(xié)議）會話協(xié)議）VersionVersion 1.001.00LightweightLightweight FixFix SessionSession LayerLayer ProtocolProtocol本規(guī)范由上海證券交易所和深圳證券交易所聯(lián)合發(fā)布本規(guī)范由上海證券交易所和深圳證券交易所聯(lián)合發(fā)布2015-08-282015-08-28Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范20

2、15-08-28II文檔說明文檔說明文檔名稱輕量級STEP會話層接口規(guī)范內容描述內容描述描述了輕量級的STEP會話協(xié)議相關內容。修訂歷史修訂歷史日期日期版本版本修訂說明修訂說明2014-01-200.8創(chuàng)建2014-3-261.00根據會員反饋意見進行修訂：1. 增加了REJECT消息 2.修正了一些文字錯誤 3. 將LFIXT協(xié)議細分為兼容模式和精簡模式，并列明協(xié)議兼容性矩陣及典型應用場景;4. 為Logon消息增補了會話狀態(tài)字段 5. 根據會員反饋意見增補了字段長度說明； 6.解釋了什么叫做Garbled Message 7.根據正文的變更修訂了附錄2014-04-101.0011. 修正

3、了tag 1408的說明文字，1.00中寫的“STEPn.x.y”并不合乎當前STEP協(xié)議的版本命名規(guī)則。2. 修正4.2節(jié)中tag 49, tag 56的說明文字及ResetSeqNumFlag的tag。3.修正附錄H中關于Reject消息檢查的一個筆誤除此之外，本版本和1.00內容并無不同。2014-08-101.0021. 補充了一些字段的最大寬度說明2. 修正MessageEncoding的說明，令缺省值為GBK2014-10-201.0011. 將版本名稱從1.002重命名重命名為1.0012015-08-281.001. 將版本名稱從1.001重命名重命名為1.00Version1

4、.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28III名詞釋義名詞釋義詞匯縮寫詞匯縮寫含義含義STEPSecurities Trading Exchange Protocol證券交易數(shù)據交換協(xié)議。FIXFinancial Information Exchange金融信息交換協(xié)議。Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28IV目錄目錄一、一、范圍范圍.1二、二、會話機制會話機制.22.1術語和定義.22.1.1會話層重傳.22.1.2應用層重傳.22.1.3NxtIn 和 NxtOut .22.1.4會話發(fā)起方和接

5、受方.22.1.5消息序號.32.1.6心跳.42.1.7有序消息處理.42.1.8可能的消息重復傳送.42.1.9可能的消息重新發(fā)送.52.1.10消息完整性.52.1.11混亂的消息(garbled message) .52.1.12消息確認.62.1.13加密.62.2會話管理.62.2.1建立會話.建立連接.身份認證.消息同步.72.2.2消息交換.72.2.3注銷會話.72.3恢復.72.3.1登錄消息處理.72.3.2重傳請求消息處理.72.3.3序號重設消息處理.8三、三、消息定義消息定義.93.1消息結構.93.1.1消息頭.93

6、.1.2消息尾.93.2管理消息.103.2.1Heartbeat 心跳消息（MsgType = 0）.113.2.2Logon 登錄消息（MsgType = A）.123.2.3TestRequest 測試請求消息（MsgType = 1）.133.2.4Resend 重發(fā)請求消息（MsgType = 2）.133.2.5Reject 會話拒絕消息（MsgType=3）.143.2.6SeqReset 序號重設消息（MsgType = 4）.163.2.7Logout 注銷消息（MsgType = 5） .16四、四、數(shù)據字典數(shù)據字典.184.1數(shù)據類型.18Version1.00輕量級輕量

7、級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28V4.2會話層域定義.19附附錄錄A .21（登錄場景）.21正常登錄場景一.21正常登錄場景二.21正常登錄場景三.22異常登錄場景一.24異常登錄場景二.24附附錄錄B.26（注銷場景）.26正常注銷場景.26附附錄錄C .27（處理重傳請求場景）.27處理重傳請求場景一.27處理重傳請求場景二.28附附錄錄D .30（處理心跳和測試請求）.30處理心跳和測試請求.30附附錄錄E.31（處理會話拒絕）.31處理會話拒絕.31附附錄錄F.32（計算校驗和）.32計算校驗和.32附附錄錄G.33（狀態(tài)轉換參考圖）.33LFIXT 會

8、話協(xié)議狀態(tài)轉換參考圖.33附附錄錄H.34（實現(xiàn)參考）.34LFIXT 會話協(xié)議實現(xiàn)參考.341.Logon 消息.342.Heartbeat 消息.353.TestRequest 消息.354.ResendRequest 消息.355.SeqReset-Reset 消息.366.SeqReset-GapFill 消息.367.Reject 消息 .378.Logout 消息.379.應用消息.37Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 1 頁共頁共 38 頁頁輕量級輕量級 STEPSTEP 會話協(xié)議接口規(guī)范會話協(xié)議接口規(guī)范一、一、范

9、圍范圍本標準對 STEP 會話層協(xié)議（即 FIX 會話層協(xié)議 FIXT 1.1 版本）進行了裁剪和改造,確立了一個基于 TCP 的輕量化 STEP 會話層協(xié)議（記作：LFIXT 會話層協(xié)議） ，同時 LFIXT 標準仍然可以保持和標準 STEP/FIX 會話層協(xié)議的互操作性。本標準規(guī)定了 LFIXT 會話層協(xié)議使用的會話機制、消息格式、安全與加密、數(shù)據完整性、擴展方式、消息定義、數(shù)據字典等內容。如無特別說明，本標準中提及的接收方、發(fā)送方等通信參與方均特指遵循 LFIXT會話層協(xié)議而實現(xiàn)的應用程序或模塊。由于遵循本協(xié)議開發(fā)的程序或模塊將可以同標準 FIX 引擎進行正常通信，因此若通信的一方是標準

10、的 FIX 引擎，則除本文特別制訂的少數(shù)額外約束外，其實現(xiàn)不受本文檔約束。Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 2 頁共頁共 38 頁頁二、二、會話機制會話機制2.1術語和定義術語和定義2.1.1 會話層重傳會話層重傳會話層重傳是標準FIX會話層協(xié)議所規(guī)定的一種重傳機制，用來確保有序、無失地傳輸每一條會話層消息。在標準FIX會話層協(xié)議中，會話層重傳由消息接收方在識別出消息序號缺口之際主動發(fā)起，采取的方式是發(fā)送一條消息重傳請求給到對方。LFIXT會話協(xié)議在事實上取消了標準FIX會話層協(xié)議的會話層重傳，只對外仍然表現(xiàn)為標準的FIX會話層

11、，且可以和對端的標準FIX會話層實現(xiàn)進行互操作。由于單個LFIXT會話使用單個TCP連接作為底層通信機制，因此在單個TCP連接內部，每一條消息將被有序、無失地傳輸。屬于同一會話的、前后相繼的若干次TCP連接之間，將可能存在會話層消息丟失，但收到的會話層消息將仍然具有有序接收的性質。由于在LFIXT下會話層可能存在消息丟失，因此丟失的業(yè)務消息將只能通過應用層重傳予以恢復。2.1.2 應用層重傳應用層重傳由于LFIXT會話協(xié)議的會話層恢復機制僅僅是為了與標準FIX會話協(xié)議兼容，不能作為真正的消息恢復機制使用。因此，必須通過應用層商定的重傳機制予以恢復。應用層重傳的具體機制不屬于本文檔規(guī)定的范疇，請

12、參見具體的應用層數(shù)據接口規(guī)范。2.1.3 NxtIn 和和 NxtOut會話雙方收發(fā)的每條消息都帶有一個消息序號。參與通信的每一端都需要維護一對序號（NxtIn，NxtOut） ，NxtIn表示下一個期望的入向消息序號，NxtOut表示下一條出向消息將被賦予的序號。2.1.4 會話發(fā)起方和接受方會話發(fā)起方和接受方會話的建立需要一個發(fā)起方，需要一個接受方。發(fā)起方是先發(fā)出Logon消息并希望對方響應以一個Logon消息的一方，接受方則是等待發(fā)起方首先發(fā)出Logon消息并響應以Logon消息的一方。會話的發(fā)起方和接受方在會話建立后都可以雙向地進行消息的發(fā)送和接收。不要將會話發(fā)起方（initiator

13、） 、會話接受方（acceptor）同某條特定消息的發(fā)送方（sender）和接收方（receiver）混為一談。類似于會話發(fā)起方和會話接受方，也定義有注銷發(fā)起方和注銷接受方、會話重置發(fā)起方和會話重置接受方的概念。Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 3 頁共頁共 38 頁頁標準FIX協(xié)議原則上適用于各種不同的傳輸層協(xié)議（如UDP） ，因此不可能根據TCP socket等特定的傳輸層信息來區(qū)分哪些報文隸屬于同一個FIX會話，而且由于FIX中并不為每個FIX會話定義有所謂“會話號”標簽，且不是全部報文都具有username一類的標簽，因

14、此區(qū)分FIX會話的唯一標識符只能是SenderCompID和TargetCompID的組合。標準FIX協(xié)議中，單個FIX引擎不能同時維護相同SenderCompID+TargetCompID的兩個會話。標準所推薦的做法是：在已存在一個合法會話時，若一方試圖以同樣的SenderCompID + TargetCompID發(fā)起新的會話，對方將不發(fā)送任何Logout消息就直接終止新發(fā)起的會話，原先已存在的會話不應受到影響。標準FIX協(xié)議并未明確不同的FIX引擎是否允許同時保有同樣標識的會話。一般而言，同一臺服務器上的同標識會話較易進行查重，針對不同服務器建立的同標識會話則較難實現(xiàn)查重，但也非無法做到。

15、LFIXT協(xié)議規(guī)定：在處理入向登錄報文時，應利用SenderCompID和TargetCompID進行會話查重，之前已存在的同標識會話一定不受影響，但較晚收到的同標識會話請求可能被接受，但也可能被拒絕，協(xié)議不作限定。若請求被拒絕，則拒絕方式將遵循標準FIX協(xié)議的約定，不回送Logout消息，直接斷開TCP連接。會話發(fā)起方應當對這種情形做好準備。LFIXT協(xié)議只允許單個會話同時通過單個TCP連接進行全雙工通信，因此在通過登錄報文信息確定是否允許繼續(xù)通信后，可以直接利用socket來區(qū)分報文所屬會話，但對于從同一socket上收到的后續(xù)報文仍應檢查其SenderCompID和TargetCompI

16、D是否和登錄時一致。2.1.5 消息序號消息序號所有的消息都由一個唯一的會話層消息序號(即消息頭中的 MsgSeqNum 字段)進行標識。消息序號在會話開始時一般被初始化為 1，并在整個會話過程中連續(xù)遞增1，直到該會話過程全部結束。通過監(jiān)視消息序號的連續(xù)性，通信雙方可以識別消息缺口并做出反應，并可在同一會話的前后多個連接間進行同步2。每次會話都會創(chuàng)建一套獨立的入向及出向的序號序列，參與連接的任何一方都維1.這個說法是針對通常情況而言的。在下述情況下，接收方收到的消息的 MsgSeqNum 也可能出現(xiàn)倒流：1)收到的消息是 SeqReset-Reset 消息且 PossDupFlag=Y，此時

17、MsgSeqNum 應忽略，即使出現(xiàn)倒流也不是錯誤；2) 除此以外，所收到消息的 PossDupFlag 是 Y，且此類消息確實允許出現(xiàn) PossDupFlag=Y，表示這是會話層重傳；3) 通過 LOGON 消息進行會話序號重置時，收到的消息其 MsgSeqNum 一定是 1，因此也可能出現(xiàn)倒流。2.LFIXT 會話協(xié)議在事實上取消了標準 FIX 會話層協(xié)議的會話層重傳，這里的同步只是為了兼容標準 Fix 會話機制，并不進行真實的消息同步。Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 4 頁共頁共 38 頁頁護一套用于出向消息的序號序列(

18、NxtOut)，同時也維護另一套獨立的入向消息的序號序列(NxtIn)，用以監(jiān)視接收的消息序號，以保證消息缺口的發(fā)現(xiàn)和處理。會話建立后，當 LFIXT 協(xié)議實現(xiàn)者接收到的消息序號不等于預期接收的消息序號(NxtIn)時，需要考慮進行修正處理。這里有幾種情況：1. 如果入向消息序號 NxtIn，且不屬于前文腳注中注明的若干種情況之一時：表明發(fā)生了嚴重的錯誤，必須立即結束會話表明發(fā)生了嚴重的錯誤，必須立即結束會話，并開始進行人工干預。2. 如果入向消息序號 NxtIn，那么表明有消息被遺漏。因為 LFIXT 使用 TCP為傳輸協(xié)議，出現(xiàn)這種情況說明發(fā)生了嚴重異常錯誤，應立刻終止當前會話說明發(fā)生了嚴

19、重異常錯誤，應立刻終止當前會話。2.1.6 心跳心跳在消息交換的空閑期間，連接雙方將以規(guī)定的時間間隔產生心跳消息。通過心跳消息可以監(jiān)控通訊連接的狀態(tài)并識別出入向消息序號的缺口。心跳間隔時間由會話發(fā)起人通過登錄消息的HeartBtInt字段確定。在傳送了任何消息(而不僅僅是心跳消息)之后，都應立即重置心跳間隔計時器。心跳間隔時間應該得到連接雙方的確認，由會話發(fā)起人給出，并得到會話接受方的確認。連接雙方應使用相同的心跳間隔時間。每個心跳消息都將占用一個MsgSeqNum消息序號。2.1.7 有序消息處理有序消息處理LFIXT會話協(xié)議采用TCP連接作為底層通信機制，會話建立后，在同一個TCP連接的延

20、續(xù)期間，接收方在發(fā)現(xiàn)入向消息缺口時，說明發(fā)生了嚴重異常，建議接收方終止該會話并斷開TCP連接。如果接收方為會話的發(fā)起方，則應根據需要重建會話。2.1.8 可能的消息重復可能的消息重復傳送傳送本會話協(xié)議采用 TCP 連接作為底層通信機制，會話雙方在建立 TCP 連接之后，通過 Logon 消息進行序號協(xié)商，其后則是基于 TCP 進行的連續(xù)通信，正常情況下，不應該出現(xiàn)前面消息丟失卻收到后面消息的情形。所以，1) 在發(fā)現(xiàn)入向消息序號缺口時，LFIXT 會話協(xié)議的實現(xiàn)者不會發(fā)送重傳請求，而是回送 Logout 后直接斷開連接，但 2)允許在入向消息中出現(xiàn)重傳請求（比如基于標準 FIX 引擎的通信對手方

21、雖然收到前面的消息但自己沒保存，并期望能按標準 FIX 會話層協(xié)議通過重傳請求取回） ，對此LFIXT 會話協(xié)議實現(xiàn)者將簡單回送 SeqReset-Reset 消息予以打發(fā)，3）允許在入向消息中出現(xiàn) PossDupFlag = Y3的消息（比如基于標準 FIX 引擎的通信對手方雖未收到本方Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 5 頁共頁共 38 頁頁發(fā)出的重傳請求，但僅僅因為懷疑本方可能錯過某些消息，而向本方發(fā)送這類PossDupFlag =Y 的消息4） 。2.1.9 可能的消息重新發(fā)送可能的消息重新發(fā)送在LFIXT會話協(xié)議中，應

22、用層重發(fā)的標志應在應用層協(xié)議中明確設置，而不應該體現(xiàn)在會話層消息的標志位上。由于互操作的對方必須遵從同樣的應用層協(xié)議，因此LFIXT會話協(xié)議將不會給出向消息打上任何Possible Resend標志。LFIXT會話協(xié)議允許在入向消息頭中出現(xiàn)Possible Resend標志，但將忽略該標志，直接將不附帶該標志的消息交由應用層處理。2.1.10 消息完整性消息完整性消息數(shù)據內容的完整性可以用兩種方式來驗證：驗證消息長度，及字符的簡單校驗和。消息長度被包括在BodyLength字段中，可以通過清點消息之中跟在BodyLength字段之后、直至并包括直接先于CheckSum域號（”10=”）出現(xiàn)的那

23、個域界定符之間的字符來驗證。校驗和的驗證方法是：從消息頭中8=中的8開始、直到并包括直接先于CheckSum 域號10=出現(xiàn)的字符，將每個字符的二進制值加總后，將計算值的最低 8 位同 CheckSum 字段中的值進行比較。2.1.11 混亂的消息混亂的消息(garbled message)根據標準 FIXT 協(xié)議的附錄，當至少出現(xiàn)以下情形之一時，一條消息被稱為“混亂的”：BeginString(tag 8) 不是消息的第一個標簽，或不以 8=FIXT.n.m 的形式出現(xiàn)。BodyLength(tag 9)不是消息的第二個標簽，或未包含正確的字節(jié)計數(shù)MsgType(tag 35) 不是消息的第

24、三個標簽CheckSum(tag 10)不是最后的標簽，或其取值不正確若 MsgSeqNum(tag 34)缺失，必須立刻終止 FIX 連接，因為這表明出現(xiàn)了嚴重的應用錯誤，很可能只能通過修改軟件來繞過。3.除了 REJECT 消息之外，其他管理消息理論上都不應被重發(fā)，而是通過發(fā)送帶有同樣消息序號的、帶有PossDupFlag 標志的 SeqReset-GapFill 消息對原消息進行替代。在此過程中，被替代的 SeqReset-GapFill 消息本身雖然仍然以同樣的消息序號、帶上同樣被置位的 PossDupFlag 標志出現(xiàn)，也被 FIX 標準解釋為“替代”而非“重發(fā)” 。4.（PossD

25、upFlag =Y）為 Y 的管理消息請參見具體的消息定義Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 6 頁共頁共 38 頁頁2.1.12 消息確認消息確認由于會話層協(xié)議是基于樂觀的消息傳輸模式，通過監(jiān)視消息序號發(fā)現(xiàn)缺口，不支持對每個消息收發(fā)的確認。但大量消息收發(fā)的確認可在應用層定義。在應用層接受和拒絕是允許的。2.1.13 加密加密LFIXT 會話層不對數(shù)據進行加密處理，會話雙方可考慮使用通信層的加密機制。2.2會話管理會話管理LFIXT 會話協(xié)議采用 TCP 連接作為底層通信機制。若 LFIXT 會話協(xié)議的實現(xiàn)者作為會話的主動發(fā)起方，

26、必須在每次新建 TCP 連接之后通過置位序號重設標志(ResetSeqNumFlag)的 Logon 消息來將起始消息序號重置回1，因此，此時會話和 TCP 連接是一一對應的。雖然 LFIXT 會話協(xié)議可以被設計成底層使用兩個獨立的 TCP 連接，每個連接都以單工模式工作，但由于在 TCP 連接上實現(xiàn)全雙工的通信并不困難且維護簡單，因此LFIXT 會話協(xié)議規(guī)定：對于單個會話而言，同時只使用一個全雙工的 TCP 連接。若 LFIXT 會話協(xié)議的實現(xiàn)者作為會話的接收方，由于該會話的發(fā)起方可能是標準的 FIX 引擎，此時建立的會話可以跨越多個 TCP 連接。在單次 TCP 連接內部，每個會話都分為三

27、個部分：建立會話、消息交換、終止會話。2.2.1 建立會話建立會話建立會話包含三個步驟：建立連接（即為建立 TCP 連接） 、身份認證、消息同步。 建立連接建立連接LFIXT 會話的發(fā)起方與接受方建立 TCP 連接。LFIXT 會話協(xié)議的實現(xiàn)者在 TCP 連接建立后，應當總是初始化 NxtIn = 1, NxtOut = 1。 身份認證身份認證1. 會話發(fā)起方發(fā)送登錄消息（Logon） ，接受方認證發(fā)起方身份的合法性。2. 如果發(fā)起方身份通過認證，則接受方發(fā)送一個登錄消息作回應。3. 如果認證失敗，會話接受方則在可選地發(fā)送一個含失敗說明的注銷消息（Logout）后關

28、閉連接。發(fā)送注銷消息并非是必須的，因為這樣做會消耗一個序號，在某些情況下可能會引起其他問題5。4. 會話發(fā)起方必須等待來自接受方的確認 Logon 消息，方可向接受方發(fā)送其他消息。否則，接受方可能尚未準備好接收它們。5.這個問題和標準 FIX 引擎對于報文所屬會話的認定方式有關 ,單在 LFIXT 引擎方面則并無不妥。Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 7 頁共頁共 38 頁頁5. 在發(fā)起方被認證后，接受方將立即回應一個確認 Logon 消息。發(fā)起方將把從接受方返回的 Logon 消息作為“一個會話已經建立”的確認。

29、 消息同步消息同步LFIXT 會話協(xié)議并不提供真正的會話層重傳機制，因此 LFIXT 會話協(xié)議的實現(xiàn)者作為會話的發(fā)起方，可通過會話重置消息（即 ResetSeqNumFlag=Y 的 Logon 消息）將會話雙方的消息序號重置，來完成會話層消息同步。LFIXT 會話協(xié)議的實現(xiàn)者作為會話接受方，可以利用 Logon 消息中的NextExpectedMsgSeqNum 來完成會話層消息同步。這種方式提供了對標準 FIX 會話協(xié)議的消息同步的兼容，具體機制參見“登錄消息處理”一節(jié)。2.2.2 消息交換消息交換在建立會話之后，會話雙方可以開始進行正常的消息交換。交換的消息包括“管理消息”和“應用消息”

30、 ，本規(guī)范僅對管理消息進行描述。應用消息請參見具體的數(shù)據接口規(guī)范。2.2.3 注銷注銷會話會話LFIXT 會話的正常結束是通過連接雙方互相發(fā)送注銷消息（Logout） ，注銷時不需要進行消息缺口檢查。若結束時沒有收到回送的注銷消息（Logout） ，則把對方視作已注銷。除此之外的其它方式的會話結束視為非正常，并應按錯誤來處理。在結束會話之前，注銷消息（Logout）的發(fā)起方應該等待對方回送的注銷消息（Logout） 。如果接收方在一定時間內沒有答復，那么會話就可以立即中斷6。2.3恢復恢復LFIXT 會話協(xié)議的會話層恢復機制是為了與標準會話協(xié)議的會話層恢復機制是為了與標準 Fix 會話協(xié)議兼容

31、，不能作為真會話協(xié)議兼容，不能作為真正的消息恢復機制使用，會話對端應通過應用層的消息恢復機制來獲得缺失的數(shù)據。正的消息恢復機制使用，會話對端應通過應用層的消息恢復機制來獲得缺失的數(shù)據。LFIXT 會話協(xié)議的實現(xiàn)者只在建立會話階段存在消息序號同步，在會話持續(xù)期間不提供真正的消息恢復，而是簡單地通過回應 SeqReset-Reset 消息來打發(fā)消息重傳請求。2.3.1 登錄消息處理登錄消息處理LFIXT 會話協(xié)議的實現(xiàn)者作為會話接收方,只需將本方 NxtIn 設置為發(fā)起方 Logon消息的 MsgSeqNum + 1，NxtOut 設置為發(fā)起方 Logon 消息中的NextExpectedMsgS

32、eqNum(789)即可。會話接收方不需要檢查任何缺口，會話接收方也不會向發(fā)起方請求重傳任何消息。如果發(fā)送方沒有提供 NextExpectedMsgSeqNum 字段，則 NxtOut 設置為 1.6.注銷不影響任何訂單的狀況。所有有效的訂單都可在注銷（Logout）之后執(zhí)行。Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 8 頁共頁共 38 頁頁2.3.2 重傳請求消息處理重傳請求消息處理作為 LFIXT 會話協(xié)議的實現(xiàn)者不會主動發(fā)送重傳請求，但可能收到標準的 FIX 會話協(xié)議實現(xiàn)者發(fā)送的重傳請求。當 LFIXT 會話協(xié)議的實現(xiàn)者收到重傳請

33、求時，會使用SeqReset-Reset 消息重置發(fā)送方序號，而不會提供歷史消息的重傳。2.3.3 序號重設消息處理序號重設消息處理LFIXT 會話協(xié)議的實現(xiàn)者收到序號重設消息時，會根據序號重設消息中的NewSeqNo 來重置本方 NxtIn。Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 9 頁共頁共 38 頁頁三、三、消息定義消息定義3.1消息結構消息結構每一條消息都由消息頭、消息體、消息尾組成。消息總是由標準消息頭開始，標準消息尾結束。3.1.1 消息頭消息頭會話雙方所有交換的消息具有如下標準的消息頭。每一個消息都由一個標準消息頭開始。

34、消息頭定義了消息的類型，長度，目的地，順序號，起始點和時間等數(shù)據域，均不加密傳輸。其中有兩個域用于消息重發(fā)。當作為會話級事件的結果而重復傳送消息時，PossDupFlag 被設置為 Y，發(fā)送時沿用原來的消息序號；當應用級重新發(fā)送消息時，使用新的消息序號，并將 PossResend 設置為 Y。接收者應按以下方法處理上述消息：PossDupFlag = Y：如果以前曾經收到過帶有該消息序號的某條消息，則忽略本消息，如果不是，則按正常步驟處理。PossResend = Y：不附帶本標志地將消息傳遞給應用層，由其確定此前是否收到該消息Tag域名域名必須必須字段描述字段描述8BeginStringY起

35、始串 FIXT.1.1(總是不加密，必須是消息的第一個域)9BodyLengthY消息體長度(總是不加密，必須是消息的第二個域)35MsgTypeY消息類型(總是不加密，必須是消息的第三個域)49SenderCompIDY發(fā)送方代碼字符串(總是不加密)56TargetCompIDY接收方代碼字符串(總是不加密)34MsgSeqNumY消息序號，整數(shù)類型43PossDupFlagN會話層可能重傳標志，重復傳送時，作此標記97PossResendN應用層可能重發(fā)標志。LFIXT 會話層協(xié)議的實現(xiàn)者不會在會話層協(xié)議的實現(xiàn)者不會在出向消息中主動設置本字段，對于入向消息中出現(xiàn)的本字出向消息中主動設置本字

36、段，對于入向消息中出現(xiàn)的本字段將簡單忽略段將簡單忽略52SendingTimeY發(fā)送時間，UTCTimestamp 類型347MessageEncodingN消息中編碼域的字符編碼類型，缺省為 GBK3.1.2 消息尾消息尾會話雙方所有交換的消息具有如下標準的消息尾。每一個消息（管理或應用消息）Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 10 頁共頁共 38 頁頁都用一個消息尾終止。消息尾可用于分隔多個消息，包含有 3 位數(shù)的校驗和值。Tag域名域名必須必須字段描述字段描述10CheckSumY校驗和，總是消息的最末域，總是不加密3.2管

37、理消息管理消息LFIXT 會話協(xié)議支持標準 FIX 會話協(xié)議的所有管理消息，但不會主動發(fā)送所有管理消息。LFIXT 會話協(xié)議分兩種模式：精簡模式和兼容模式，各自有不同的使用范圍。已知通信對手方為 LFIXT 會話協(xié)議實現(xiàn)者時，可以采用精簡模式，此時只需要支持如下消息的接收和發(fā)送處理。此時由于本方不會主動發(fā)送 ResendRequest，因此根據協(xié)議也不會觸發(fā)對方回應 SeqReset-Reset，因此不需要處理入向的 SeqReset-Reset 消息：管理消息類型管理消息類型來自對方來自對方本方發(fā)送本方發(fā)送Heartbeat是是Logon是是Reject是是Logout是是表 1精簡模式：僅

38、和 LFIXT 實現(xiàn)者通信時當需要和基于標準 FIX 引擎的對手方進行通信時，必須采用兼容模式。此時LFIXT 會話協(xié)議實現(xiàn)者需要支持所有管理消息的接收，但仍然不需要支持所有管理消息的發(fā)送。兼容模式和精簡模式主要的區(qū)別只在于前者需要處理更多的入向管理消息。管理消息類型管理消息類型來自對方來自對方本方發(fā)送本方發(fā)送Heartbeat是是Logon是是TestRequest是否ResendRequest是否Reject是是SeqReset-Reset是是SeqReset-GapFill是否Logout是是表 2兼容模式：和標準 FIX 會話協(xié)議實現(xiàn)者通信時Version1.00輕量級輕量級 STEP

39、 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 11 頁共頁共 38 頁頁一般而言，交易所端的 LFIXT 引擎應采用兼容模式以取得最大程度的協(xié)議兼容性。在已知交易所端采用兼容模式 LFIXT 協(xié)議的前提下，券商端可以選用精簡模式的LFIXT 協(xié)議，從而用最小的代價實現(xiàn)交易所接入，自然也可以考慮采用兼容模式甚至是標準 FIX 會話層協(xié)議完成交易所接入。必須注意：精簡模式的 LFIXT 協(xié)議實現(xiàn)簡便，但不具備和標準 FIX 協(xié)議互通的能力，券商必須全面衡量各系統(tǒng)的總體成本以確定實際使用的協(xié)議。標準 FIX 協(xié)議兼容模式 LFIXT精簡模式 LFIXT標準 FIX 協(xié)議兼容模式 LFIXT

40、精簡模式 LFIXT表 3協(xié)議兼容性矩陣3.2.1 Heartbeat 心跳消息（心跳消息（MsgType = 0）會話雙方使用 Heartbeat 消息來檢測當前使用的 TCP 連接的狀態(tài)，因此當一方處于數(shù)據發(fā)送空閑期時，需要定時發(fā)送 Heartbeat 消息以供檢測鏈接的健康度。接收方如果在兩倍的（HeartBtInt合理傳輸時間 ）內沒有收到來自對方的心跳消息，就認為連接失敗，此時可以不發(fā)送 Logout 消息，立即關閉 TCP 連接。會話協(xié)議不會主動發(fā)送 TestRequest 消息，但 LFIXT 會話協(xié)議的實現(xiàn)者，為了與標準 FIX 會話協(xié)議的兼容，如果收到了 TestReques

41、t 請求，會按標準 FIX 會話協(xié)議向發(fā)送方返回心跳響應。如果上層應用定義有應用層心跳信息，并以不低于 HeartBtInt 的間隔主動發(fā)送，則在事實上使得會話層心跳消息的發(fā)送條件永遠得不到滿足。在這種情況下，一方即使只收到應用層心跳消息，永遠也收不到來自對方的會話層心跳消息，也不構成對本協(xié)議的違反。Tag域名域名必須必須字段描述字段描述Standard HeaderYMsgType = 0112TestReqIDN字符串。如是對 TestRequest 響應而發(fā)送的心跳消息，則應包含本域。本域的內容直接來自于觸發(fā)本心跳消息的Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接

42、口規(guī)范2015-08-28第第 12 頁共頁共 38 頁頁TestRequest 消息的內容Standard TrailerY3.2.2 Logon 登錄消息（登錄消息（MsgType = A）登錄消息應是請求建立一個會話的應用所發(fā)送的第一個消息。HeartBtInt(108)域用來聲明產生心跳的超時間隔（連接雙方使用相同的值） 。連接雙方事先約定取值，由登錄發(fā)起方產生，并得到登錄接受方的確認響應。當收到登錄消息時，會話接受方將驗證發(fā)起方身份的合法性，并且發(fā)出登錄消息作為連接請求已被接受的確認。同樣，確認的登錄消息也可以被發(fā)起方用以驗證連接是與正確的對方建立的。會話接受方應在收到登錄消息之后，

43、立即作好開始消息處理的準備。本標準規(guī)定：必須等到返回的登錄消息收到之后才實施正常的消息交換。LFIXT 會話協(xié)議實現(xiàn)著若作為會話發(fā)起方，其發(fā)送的 Logon 消息需將MsgSeqNum 設置為 1、ResetSeqNumFlag 設置為 Y、NextExpectedMsgSeqNum 設置為1。標準 FIX 引擎若要向 LFIXT 協(xié)議實現(xiàn)者發(fā)起會話，且選擇采用NextExpectedMsgSeqNum(789)來實現(xiàn)序號同步，必須在 Logon 消息中將該字段填寫為標準 FIX 引擎已保存的入向消息的最大序號 + 1。比如標準 FIX 引擎保存了入向消息1-7，沒有保存入向消息 8 和 9，

44、但保存了入向消息 10，此時應該填寫此字段為 11，而非 8。這一點在這一點在 FIXT 協(xié)議中并未明確規(guī)定，故本文檔對此予以特別限定協(xié)議中并未明確規(guī)定，故本文檔對此予以特別限定。Tag域名域名必須必須字段描述字段描述Standard HeaderYMsgType = A98EncryptMethodY加密方法始終為 0，即不加密108HeartBtIntY心跳間隔，單位是秒。雙方必須用同一個值141ResetSeqNumFlagN雙方序號重設回 1 的標志，布爾型789NextExpectedMsgSeqNumN接收方期望得到的下一條消息序號，可選。若不填寫，認為取值為 1553Userna

45、meN用戶名554PasswordN密碼1137DefaultApplVerIDY本次會話中使用的 FIX 消息的缺省版本。1407DefaultApplExtIDN本次會話中使用的 FIX 消息在 Tag1137 基礎上的缺省擴展包。Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 13 頁共頁共 38 頁頁1408DefaultCstmApplVerIDN本次會話中，F(xiàn)IX 消息的缺省自定義應用版本。本標簽是對 tag 1137 + tag 1407 的進一步約束。本字段必須填寫交易所發(fā)布的數(shù)據接口規(guī)范版本。如果接入方不提供該字段，接收方將

46、不會允許接入方接入，并會通過 Logout 消息終止該會話。Standard TrailerY3.2.3 TestRequest 測試請求消息（測試請求消息（MsgType = 1）測試請求消息能強制對方發(fā)出心跳消息。會話協(xié)議不會主動發(fā)送該消息。測試請求消息的作用是檢查對方消息序號和檢查通信線路的狀況。對方用帶有測試請求標識符（TestReqID）的心跳作應答。LFIXT 協(xié)議的實現(xiàn)方不會主動發(fā)送任何 TestRequest消息Tag域名域名必須必須注釋注釋Standard HeaderYMsgType = 1112TestReqIDN測試請求標識符Standard TrailerY3.2.4

47、 Resend 重發(fā)請求消息（重發(fā)請求消息（MsgType = 2）重發(fā)請求消息由接收方發(fā)出，目的是向發(fā)送方申請某些消息重復發(fā)送。LFIXT 會話協(xié)議不會主動發(fā)送該消息。重發(fā)請求消息有以下幾種表示方式：請求重發(fā)一條消息：BeginSeqNo= EndSeqNo請求重發(fā)某個范圍內的消息： BeginSeqNo=該范圍中的第 1 條消息序號，EndSeqNo=該范圍中的最后一條消息序號。注意請求重發(fā)一條消息只是本形式的特例。請求重發(fā)某一特定消息之后的所有的消息：BeginSeqNo=該范圍中的第 1 條消息， EndSeqNo=0（代表無窮大）LFIXT 會話協(xié)議的實現(xiàn)者作為本消息的接收方時，只會

48、通過 SeqReset-Reset 消息響應標準 FIX 會話協(xié)議實現(xiàn)者發(fā)送的重傳請求消息。Tag域名域名必須必須注釋注釋Standard HeaderYMsgType = 2Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 14 頁共頁共 38 頁頁7BeginSeqNoY起始消息序號16EndSeqNoY結束消息序號Standard TrailerY3.2.5 Reject 會話拒絕消息（會話拒絕消息（MsgType=3）當接收方收到一條消息，由于違反了會話層規(guī)則會話層規(guī)則而不能適當?shù)靥幚碓撓r，應該發(fā)出 Reject（拒絕）消息。發(fā)出

49、Reject 消息可能是合適的一個例子是：收到了一條成功經過解碼、校驗和檢查及 BodyLength 檢查的消息，但該消息帶有不合法的基本數(shù)據（比如：MsgType = &） 。規(guī)則要求：只要可能，消息應盡可能盡可能被轉發(fā)給交易程序并通過業(yè)務層拒絕（而非會話層的 Reject 消息）來響應。若收到一條滿足會話層規(guī)則的應用層消息，它必須在業(yè)務消息的層面被處理。若此處理過程發(fā)現(xiàn)了規(guī)則的違反，則應當產生一條業(yè)務層拒絕消息。許多業(yè)務層消息有特有的“拒絕”消息，應該使用這些消息。全部其他情況都可以通過“業(yè)務消息拒絕消息”進行拒絕。注意，即使收到了業(yè)務消息，且滿足會話層規(guī)則，但當此消息不能被送達業(yè)

50、務層處理系統(tǒng)的時候，也應該發(fā)送一條BusinessRejectReason=“應用此刻不存在”的“業(yè)務消息拒絕”消息。被拒絕的消息應該被記錄日志，且入向序號應該增加。和標準 FIX 會話協(xié)議不同之處在于：在 LFIXT 會話協(xié)議中，如果收到的消息是混亂的(garbled)，或者說：不能被解析或不能通過數(shù)據完整性檢查時，應當記錄日志后回送 Logout 消息并立刻斷開連接（在標準 FIX 會話協(xié)議中建議忽略并丟棄本消息，以期望后續(xù)收到的正確格式的消息能觸發(fā)一個消息缺口，從而能通過重傳請求再度拿回這條混亂的消息） 。同時也需要注意：這并非會話層 Reject 消息的使用場景。產生和收到 Rejec

51、t 消息，意味著出現(xiàn)了嚴重錯誤，可能發(fā)送方或接收方的應用存在邏輯錯誤。如果發(fā)送方應用選擇重新發(fā)送被拒絕的消息，應當使用新的消息序號并設置PossResend = Y。因為 PossResend = Y 的語義是可能的應用層重發(fā)，因此這里被重新發(fā)送的一定是指應用層消息而非管理消息。只要有可能，強烈推薦在本消息的 Text 字段中描述引起錯誤的原因。當收到 Reject 消息本身時，建議記錄日志，然后調整入向序號。TagTag域名域名必需必需說明說明Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 15 頁共頁共 38 頁頁Standard Hea

52、derYMsgType=345RefSeqNumY關聯(lián)消息的序號，即被拒絕消息(對方發(fā)送且己方收到)的序號。371RefTagIDN相關錯誤消息中，出現(xiàn)錯誤的 FIX 域號372RefMsgTypeN相關錯誤消息的 MsgType373SessionRejectReasonN會話拒絕原因編號58TextN文本，可解釋拒絕的原因Standard TrailerY會話拒絕原因會話拒絕原因(SessionRejectReason)0 =無效域號1 = 該消息中必須的域丟失2 = 該消息中出現(xiàn)未曾定義的域3 = 未定義的域號4 = 聲明了域，但未賦值5 = 此域的值錯誤（范圍溢出）6 = 取值格式錯誤

53、7 = 解密錯誤8 = 簽名錯誤9 = CompID 錯誤10 = 發(fā)送時間精度錯誤11 = 無效的 MsgType12 = XML 驗證錯誤13 =域多次出現(xiàn)（非重復組）14 = 有序的域出現(xiàn)次序錯誤15 = 重復組中，域次序錯誤16 = 重復組中，NumInGroup 錯誤17 = 非 data 數(shù)據域中，出現(xiàn)域界定符99 = 其他。注意可能存在其他的會話層規(guī)則違反，此時， “會話拒絕原因”99 可以被使用，進一步的信息應當包括在 Text 字段中。表 4會話拒絕場景Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 16 頁共頁共 38 頁

54、頁3.2.6 SeqReset 序號重設消息（序號重設消息（MsgType = 4）序號重設消息由發(fā)送方發(fā)出，用于告知接收方下一個消息的消息序號。序號重設消息有兩種模式：序號重設-缺口填補（SeqReset-Gap Fill） ；序號重設-重設（SeqReset -Reset） 。在 LFIXT 會話協(xié)議中，只使用 SeqReset-Reset 消息回應 ResendRequest 消息，此SeqReset-Reset 消息的 MsgSeqNum 按標準 FIX 協(xié)議規(guī)定可以任意填寫且接收方不會檢查，在 LFIXT 中規(guī)定固定填寫 1，其中的 NewSeqNo 則建議填寫為maxResendR

55、equest 消息的 EndSeqNo 字段值，本方 NxtOut 值。序號重設只能增加消息序號。如果收到的序號重設消息試圖使下一個預期的消息序號變小，那么此消息應被拒絕接受，并被視作為嚴重錯誤。在 LFIXT 會話協(xié)議中，雖然不會主動發(fā)起重傳請求，但仍然有可能收到標準 FIX協(xié)議的對手方主動發(fā)出的 SeqReset 類消息。當收到的序號重設消息為 SeqReset-GapFill 消息時，必須確保 NewSeqNo 必須大于等于 SeqReset-GapFill 消息本身的 MsgSeqNum + 1 且不允許 NewSeqNo NxtIn，此時本方 NxtIn 保持不變；否則，被視為嚴重錯

56、誤。當收到 SeqReset-Reset 消息時，則需要忽略 MsgSeqNum 的檢查，同時令本方NxtIn = NewSeqNo。Tag域名域名必須必須注釋注釋Standard HeaderYMsgType = 4123GapFillFlagN缺口填補標志。布爾型。 “Y”表明是 Gap Fill 模式；“N”或不存在本域，表明是Reset 模式。36NewSeqNoY新消息序號Standard TrailerY3.2.7 Logout 注銷消息（注銷消息（MsgType = 5）注銷消息是發(fā)起或確認會話終止的消息。未經注銷消息的交換而斷開連接，一律視為非正常的斷開。在最后終止會話之前，注

57、銷的發(fā)起人應該等待連接對方確認注銷消息。如果連接對方沒有在適當?shù)臅r間間隔里作回應，那么會話就可以終止。注銷發(fā)起人在發(fā)送注銷消息之后不應發(fā)送任何消息，除非接收到連接對方發(fā)出的重傳請求消息。何時發(fā)送 Logout，何時直接斷開Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 17 頁共頁共 38 頁頁一般而言，在關閉連接前推薦的做法是回送一條 Logout 消息以利于對端診斷連接斷開的原因。但此處可有一些例外：1. 若收到的登錄報文中，SenderCompID, TargetCompID 或者會話發(fā)起方的 IP 地址不合法，推薦做法是會話立即終止，

58、不發(fā)送任何 Logout 消息。原因是此種登錄嘗試很可能屬于未被授權的系統(tǒng)入侵行為，因此不應當回送 Logout 消息以泄露 FIX 版本、合法 SenderCompID、TargetCompID 等信息。2. 在標準 FIXT 協(xié)議中，在收到登錄請求時若在同一個 FIX 引擎若已存在一個合法的相同 KEY 的會話，則標準 FIX 引擎將直接斷開后來的登錄請求所欲發(fā)起的會話。由于任何時刻總是存在網絡中斷的可能，因此 LFIXT 協(xié)議的任何參與方都應該對于沒有收到對方的 Logout 消息但底層 TCP 連接卻已關閉的情況做好準備。在斷開連接前回送 Logout 消息是推薦行為，但非必須。在此簡

59、要總結一下：對于收到報文中的各類異常接收方通常處理的原則。1. TCP 通信異常/潛在的惡意攻擊推薦處理方式是直接斷開 TCP 連接。由于在任何情況下通信參與者都必須能夠處理 TCP 連接的中斷，因此這也是缺省處理辦法。對于同一個 TCP 連接上，第一個收到的報文不是正確的 Logon 報文，或者在已經Logon 成功的 TCP 連接上又收到一個普通的 Logon 消息，視作惡意攻擊，直接斷開。2. 混亂的報文、入向消息序號出現(xiàn)缺口推薦處理方式是回送 Logout 消息，然后斷開 TCP 連接3. 報文不混亂，但不滿足會話層規(guī)則推薦處理方式是發(fā)送 Reject 拒絕此消息，會話繼續(xù)4. 報文不

60、混亂，滿足會話層規(guī)則交給應用層去處理。如果應用層發(fā)現(xiàn)報文違反了應用層規(guī)則，回送應用層拒絕消息，會話繼續(xù)Tag域名域名必須必須字段描述字段描述Standard HeaderYMsgType = 5Version1.00輕量級輕量級 STEP 會話層接口規(guī)范會話層接口規(guī)范2015-08-28第第 18 頁共頁共 38 頁頁1409SessionStatusNLogout 時的會話狀態(tài)。根據 FIX 協(xié)議有如下取值：0 = 會話活躍1 = 會話口令已更改2 = 將過期的會話口令3 = 新會話口令不符合規(guī)范4 = 會話退登完成5 = 不合法的用戶名或口令6 = 賬戶鎖定7 = 當前時間不允許登錄8 = 口令過