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

Version1.00 輕量級STEP會話層接口規(guī)范 2015-08-28 PAGEV輕量級STEP會話層接口規(guī)范（LFIXT會話協(xié)議）Version1.00LightweightFixSessionLayerProtocol本規(guī)范由上海證券交易所和深圳證券交易所聯(lián)合發(fā)布2015-08-28

文檔說明文檔名稱輕量級STEP會話層接口規(guī)范內(nèi)容描述描述了輕量級的STEP會話協(xié)議相關(guān)內(nèi)容。修訂歷史日期版本修訂說明2014-01-200.8創(chuàng)建2014-3-261.00α根據(jù)會員反饋意見進行修訂：1.增加了REJECT消息2.修正了一些文字錯誤3.將LFIXT協(xié)議細分為兼容模式和精簡模式，并列明協(xié)議兼容性矩陣及典型應用場景;4.為Logon消息增補了會話狀態(tài)字段5.根據(jù)會員反饋意見增補了字段長度說明；6.解釋了什么叫做GarbledMessage7.根據(jù)正文的變更修訂了附錄2014-04-101.00α11.修正了tag1408的說明文字，1.00α中寫的“STEPn.x.y”并不合乎當前STEP協(xié)議的版本命名規(guī)則。2.修正4.2節(jié)中tag49,tag56的說明文字及ResetSeqNumFlag的tag。3.修正附錄H中關(guān)于Reject消息檢查的一個筆誤除此之外，本版本和1.00α內(nèi)容并無不同。2014-08-101.00α21.補充了一些字段的最大寬度說明2.修正MessageEncoding的說明，令缺省值為GBK2014-10-201.00β11.將版本名稱從1.00α2重命名為1.00β12015-08-281.001.將版本名稱從1.00β1重命名為1.00

名詞釋義詞匯縮寫含義STEPSecuritiesTradingExchangeProtocol證券交易數(shù)據(jù)交換協(xié)議。FIXFinancialInformationExchange金融信息交換協(xié)議。

目錄TOC\o"1-4"\h\z\u一、 范圍 1二、 會話機制 22.1 術(shù)語和定義 22.1.1 會話層重傳 22.1.2 應用層重傳 22.1.3 NxtIn和NxtOut 22.1.4 會話發(fā)起方和接受方 22.1.5 消息序號 32.1.6 心跳 42.1.7 有序消息處理 42.1.8 可能的消息重復傳送 42.1.9 可能的消息重新發(fā)送 52.1.10 消息完整性 52.1.11 混亂的消息(garbledmessage) 52.1.12 消息確認 62.1.13 加密 62.2 會話管理 62.2.1 建立會話 6 建立連接 6 身份認證 6 消息同步 72.2.2 消息交換 72.2.3 注銷會話 72.3 恢復 72.3.1 登錄消息處理 72.3.2 重傳請求消息處理 72.3.3 序號重設消息處理 8三、 消息定義 93.1 消息結(jié)構(gòu) 93.1.1 消息頭 93.1.2 消息尾 93.2 管理消息 103.2.1 Heartbeat心跳消息（MsgType=0） 113.2.2 Logon登錄消息（MsgType=A） 123.2.3 TestRequest測試請求消息（MsgType=1） 133.2.4 Resend重發(fā)請求消息（MsgType=2） 133.2.5 Reject會話拒絕消息（MsgType=3） 143.2.6 SeqReset序號重設消息（MsgType=4） 163.2.7 Logout注銷消息（MsgType=5） 16四、 數(shù)據(jù)字典 184.1 數(shù)據(jù)類型 184.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)轉(zhuǎn)換參考圖） 33LFIXT會話協(xié)議狀態(tài)轉(zhuǎn)換參考圖 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ī)范 2015-08-28第38頁共=NUMPAGES43-538頁輕量級STEP會話協(xié)議接口規(guī)范范圍本標準對STEP會話層協(xié)議（即FIX會話層協(xié)議FIXT1.1版本）進行了裁剪和改造,確立了一個基于TCP的輕量化STEP會話層協(xié)議（記作：LFIXT會話層協(xié)議），同時LFIXT標準仍然可以保持和標準STEP/FIX會話層協(xié)議的互操作性。本標準規(guī)定了LFIXT會話層協(xié)議使用的會話機制、消息格式、安全與加密、數(shù)據(jù)完整性、擴展方式、消息定義、數(shù)據(jù)字典等內(nèi)容。如無特別說明，本標準中提及的接收方、發(fā)送方等通信參與方均特指遵循LFIXT會話層協(xié)議而實現(xiàn)的應用程序或模塊。由于遵循本協(xié)議開發(fā)的程序或模塊將可以同標準FIX引擎進行正常通信，因此若通信的一方是標準的FIX引擎，則除本文特別制訂的少數(shù)額外約束外，其實現(xiàn)不受本文檔約束。

會話機制術(shù)語和定義會話層重傳會話層重傳是標準FIX會話層協(xié)議所規(guī)定的一種重傳機制，用來確保有序、無失地傳輸每一條會話層消息。在標準FIX會話層協(xié)議中，會話層重傳由消息接收方在識別出消息序號缺口之際主動發(fā)起，采取的方式是發(fā)送一條消息重傳請求給到對方。LFIXT會話協(xié)議在事實上取消了標準FIX會話層協(xié)議的會話層重傳，只對外仍然表現(xiàn)為標準的FIX會話層，且可以和對端的標準FIX會話層實現(xiàn)進行互操作。由于單個LFIXT會話使用單個TCP連接作為底層通信機制，因此在單個TCP連接內(nèi)部，每一條消息將被有序、無失地傳輸。屬于同一會話的、前后相繼的若干次TCP連接之間，將可能存在會話層消息丟失，但收到的會話層消息將仍然具有有序接收的性質(zhì)。由于在LFIXT下會話層可能存在消息丟失，因此丟失的業(yè)務消息將只能通過應用層重傳予以恢復。應用層重傳由于LFIXT會話協(xié)議的會話層恢復機制僅僅是為了與標準FIX會話協(xié)議兼容，不能作為真正的消息恢復機制使用。因此，必須通過應用層商定的重傳機制予以恢復。應用層重傳的具體機制不屬于本文檔規(guī)定的范疇，請參見具體的應用層數(shù)據(jù)接口規(guī)范。NxtIn和NxtOut會話雙方收發(fā)的每條消息都帶有一個消息序號。參與通信的每一端都需要維護一對序號（NxtIn，NxtOut），NxtIn表示下一個期望的入向消息序號，NxtOut表示下一條出向消息將被賦予的序號。會話發(fā)起方和接受方會話的建立需要一個發(fā)起方，需要一個接受方。發(fā)起方是先發(fā)出Logon消息并希望對方響應以一個Logon消息的一方，接受方則是等待發(fā)起方首先發(fā)出Logon消息并響應以Logon消息的一方。會話的發(fā)起方和接受方在會話建立后都可以雙向地進行消息的發(fā)送和接收。不要將會話發(fā)起方（initiator）、會話接受方（acceptor）同某條特定消息的發(fā)送方（sender）和接收方（receiver）混為一談。類似于會話發(fā)起方和會話接受方，也定義有注銷發(fā)起方和注銷接受方、會話重置發(fā)起方和會話重置接受方的概念。標準FIX協(xié)議原則上適用于各種不同的傳輸層協(xié)議（如UDP），因此不可能根據(jù)TCPsocket等特定的傳輸層信息來區(qū)分哪些報文隸屬于同一個FIX會話，而且由于FIX中并不為每個FIX會話定義有所謂“會話號”標簽，且不是全部報文都具有username一類的標簽，因此區(qū)分FIX會話的唯一標識符只能是SenderCompID和TargetCompID的組合。標準FIX協(xié)議中，單個FIX引擎不能同時維護相同SenderCompID+TargetCompID的兩個會話。標準所推薦的做法是：在已存在一個合法會話時，若一方試圖以同樣的SenderCompID+TargetCompID發(fā)起新的會話，對方將不發(fā)送任何Logout消息就直接終止新發(fā)起的會話，原先已存在的會話不應受到影響。標準FIX協(xié)議并未明確不同的FIX引擎是否允許同時保有同樣標識的會話。一般而言，同一臺服務器上的同標識會話較易進行查重，針對不同服務器建立的同標識會話則較難實現(xiàn)查重，但也非無法做到。LFIXT協(xié)議規(guī)定：在處理入向登錄報文時，應利用SenderCompID和TargetCompID進行會話查重，之前已存在的同標識會話一定不受影響，但較晚收到的同標識會話請求可能被接受，但也可能被拒絕，協(xié)議不作限定。若請求被拒絕，則拒絕方式將遵循標準FIX協(xié)議的約定，不回送Logout消息，直接斷開TCP連接。會話發(fā)起方應當對這種情形做好準備。LFIXT協(xié)議只允許單個會話同時通過單個TCP連接進行全雙工通信，因此在通過登錄報文信息確定是否允許繼續(xù)通信后，可以直接利用socket來區(qū)分報文所屬會話，但對于從同一socket上收到的后續(xù)報文仍應檢查其SenderCompID和TargetCompID是否和登錄時一致。消息序號所有的消息都由一個唯一的會話層消息序號(即消息頭中的MsgSeqNum字段)進行標識。消息序號在會話開始時[一般]被初始化為1，并在整個會話過程中連續(xù)遞增這個說法是針對通常情況而言的。在下述情況下，接收方收到的消息的MsgSeqNum也可能出現(xiàn)倒流：1)收到的消息是SeqReset-Reset消息且PossDupFlag=Y，此時MsgSeqNum應忽略，即使出現(xiàn)倒流也不是錯誤；2)除此以外，所收到消息的PossDupFlag是Y，且此類消息確實允許出現(xiàn)PossDupFlag=Y，表示這是會話層重傳；3)這個說法是針對通常情況而言的。在下述情況下，接收方收到的消息的MsgSeqNum也可能出現(xiàn)倒流：1)收到的消息是SeqReset-Reset消息且PossDupFlag=Y，此時MsgSeqNum應忽略，即使出現(xiàn)倒流也不是錯誤；2)除此以外，所收到消息的PossDupFlag是Y，且此類消息確實允許出現(xiàn)PossDupFlag=Y，表示這是會話層重傳；3)通過LOGON消息進行會話序號重置時，收到的消息其MsgSeqNum一定是1，因此也可能出現(xiàn)倒流。LFIXT會話協(xié)議在事實上取消了標準FIX會話層協(xié)議的會話層重傳，這里的同步只是為了兼容標準Fix會話機制，并不進行真實的消息同步。每次會話都會創(chuàng)建一套獨立的入向及出向的序號序列，參與連接的任何一方都維護一套用于出向消息的序號序列(NxtOut)，同時也維護另一套獨立的入向消息的序號序列(NxtIn)，用以監(jiān)視接收的消息序號，以保證消息缺口的發(fā)現(xiàn)和處理。會話建立后，當LFIXT協(xié)議實現(xiàn)者接收到的消息序號不等于預期接收的消息序號(NxtIn)時，需要考慮進行修正處理。這里有幾種情況：如果入向消息序號<NxtIn，且不屬于前文腳注中注明的若干種情況之一時：表明發(fā)生了嚴重的錯誤，必須立即結(jié)束會話，并開始進行人工干預。如果入向消息序號<NxtIn，且屬于前文腳注中注明的若干種情況之一，不屬于錯誤，應進行正常處理。如果入向消息序號>NxtIn，那么表明有消息被遺漏。因為LFIXT使用TCP為傳輸協(xié)議，出現(xiàn)這種情況說明發(fā)生了嚴重異常錯誤，應立刻終止當前會話。心跳在消息交換的空閑期間，連接雙方將以規(guī)定的時間間隔產(chǎn)生心跳消息。通過心跳消息可以監(jiān)控通訊連接的狀態(tài)并識別出入向消息序號的缺口。心跳間隔時間由會話發(fā)起人通過登錄消息的HeartBtInt字段確定。在傳送了任何消息(而不僅僅是心跳消息)之后，都應立即重置心跳間隔計時器。心跳間隔時間應該得到連接雙方的確認，由會話發(fā)起人給出，并得到會話接受方的確認。連接雙方應使用相同的心跳間隔時間。每個心跳消息都將占用一個MsgSeqNum消息序號。有序消息處理LFIXT會話協(xié)議采用TCP連接作為底層通信機制，會話建立后，在同一個TCP連接的延續(xù)期間，接收方在發(fā)現(xiàn)入向消息缺口時，說明發(fā)生了嚴重異常，建議接收方終止該會話并斷開TCP連接。如果接收方為會話的發(fā)起方，則應根據(jù)需要重建會話?？赡艿南⒅貜蛡魉捅緯拝f(xié)議采用TCP連接作為底層通信機制，會話雙方在建立TCP連接之后，通過Logon消息進行序號協(xié)商，其后則是基于TCP進行的連續(xù)通信，正常情況下，不應該出現(xiàn)前面消息丟失卻收到后面消息的情形。所以，1)在發(fā)現(xiàn)入向消息序號缺口時，LFIXT會話協(xié)議的實現(xiàn)者不會發(fā)送重傳請求，而是回送Logout后直接斷開連接，但2)允許在入向消息中出現(xiàn)重傳請求（比如基于標準FIX引擎的通信對手方雖然收到前面的消息但自己沒保存，并期望能按標準FIX會話層協(xié)議通過重傳請求取回），對此LFIXT會話協(xié)議實現(xiàn)者將簡單回送SeqReset-Reset消息予以打發(fā)，3）允許在入向消息中出現(xiàn)PossDupFlag=Y除了REJECT消息之外，其他管理消息理論上都不應被重發(fā)，而是通過發(fā)送帶有同樣消息序號的、帶有PossDupFlag標志的SeqReset-GapFill消息對原消息進行替代。在此過程中，被替代的SeqReset-GapFill消息本身雖然仍然以同樣的消息序號、帶上同樣被置位的PossDupFlag標志出現(xiàn)，也被FIX標準解釋為“替代”除了REJECT消息之外，其他管理消息理論上都不應被重發(fā)，而是通過發(fā)送帶有同樣消息序號的、帶有PossDupFlag標志的SeqReset-GapFill消息對原消息進行替代。在此過程中，被替代的SeqReset-GapFill消息本身雖然仍然以同樣的消息序號、帶上同樣被置位的PossDupFlag標志出現(xiàn)，也被FIX標準解釋為“替代”而非“重發(fā)”。（PossDupFlag=Y）為Y的管理消息請參見具體的消息定義可能的消息重新發(fā)送在LFIXT會話協(xié)議中，應用層重發(fā)的標志應在應用層協(xié)議中明確設置，而不應該體現(xiàn)在會話層消息的標志位上。由于互操作的對方必須遵從同樣的應用層協(xié)議，因此LFIXT會話協(xié)議將不會給出向消息打上任何PossibleResend標志。LFIXT會話協(xié)議允許在入向消息頭中出現(xiàn)PossibleResend標志，但將忽略該標志，直接將不附帶該標志的消息交由應用層處理。消息完整性消息數(shù)據(jù)內(nèi)容的完整性可以用兩種方式來驗證：驗證消息長度，及字符的簡單校驗和。消息長度被包括在BodyLength字段中，可以通過清點消息之中跟在BodyLength字段之后、直至并包括直接先于CheckSum域號（”10=”）出現(xiàn)的那個域界定符<SOH>之間的字符來驗證。校驗和的驗證方法是：從消息頭中‘8=’中的‘8’開始、直到并包括直接先于CheckSum域號‘10=’出現(xiàn)的<SOH>字符，將每個字符的二進制值加總后，將計算值的最低8位同CheckSum字段中的值進行比較?；靵y的消息(garbledmessage)根據(jù)標準FIXT協(xié)議的附錄，當至少出現(xiàn)以下情形之一時，一條消息被稱為“混亂的”：BeginString(tag8)不是消息的第一個標簽，或不以8=FIXT.n.m的形式出現(xiàn)。BodyLength(tag9)不是消息的第二個標簽，或未包含正確的字節(jié)計數(shù)MsgType(tag35)不是消息的第三個標簽CheckSum(tag10)不是最后的標簽，或其取值不正確若MsgSeqNum(tag34)缺失，必須立刻終止FIX連接，因為這表明出現(xiàn)了嚴重的應用錯誤，很可能只能通過修改軟件來繞過。消息確認由于會話層協(xié)議是基于樂觀的消息傳輸模式，通過監(jiān)視消息序號發(fā)現(xiàn)缺口，不支持對每個消息收發(fā)的確認。但大量消息收發(fā)的確認可在應用層定義。在應用層接受和拒絕是允許的。加密LFIXT會話層不對數(shù)據(jù)進行加密處理，會話雙方可考慮使用通信層的加密機制。會話管理LFIXT會話協(xié)議采用TCP連接作為底層通信機制。若LFIXT會話協(xié)議的實現(xiàn)者作為會話的主動發(fā)起方，必須在每次新建TCP連接之后通過置位序號重設標志(ResetSeqNumFlag)的Logon消息來將起始消息序號重置回1，因此，此時會話和TCP連接是一一對應的。雖然LFIXT會話協(xié)議可以被設計成底層使用兩個獨立的TCP連接，每個連接都以單工模式工作，但由于在TCP連接上實現(xiàn)全雙工的通信并不困難且維護簡單，因此LFIXT會話協(xié)議規(guī)定：對于單個會話而言，同時只使用一個全雙工的TCP連接。若LFIXT會話協(xié)議的實現(xiàn)者作為會話的接收方，由于該會話的發(fā)起方可能是標準的FIX引擎，此時建立的會話可以跨越多個TCP連接。在單次TCP連接內(nèi)部，每個會話都分為三個部分：建立會話、消息交換、終止會話。建立會話建立會話包含三個步驟：建立連接（即為建立TCP連接）、身份認證、消息同步。建立連接LFIXT會話的發(fā)起方與接受方建立TCP連接。LFIXT會話協(xié)議的實現(xiàn)者在TCP連接建立后，應當總是初始化NxtIn=1,NxtOut=1。身份認證會話發(fā)起方發(fā)送登錄消息（Logon），接受方認證發(fā)起方身份的合法性。如果發(fā)起方身份通過認證，則接受方發(fā)送一個登錄消息作回應。如果認證失敗，會話接受方則在可選地發(fā)送一個含失敗說明的注銷消息（Logout）后關(guān)閉連接。發(fā)送注銷消息并非是必須的，因為這樣做會消耗一個序號，在某些情況下可能會引起其他問題這個問題和標準FIX引擎對于報文所屬會話的認定方式有關(guān),單在LFIXT引擎方面則并無不妥。。這個問題和標準FIX引擎對于報文所屬會話的認定方式有關(guān),單在LFIXT引擎方面則并無不妥。會話發(fā)起方必須等待來自接受方的確認Logon消息，方可向接受方發(fā)送其他消息。否則，接受方可能尚未準備好接收它們。在發(fā)起方被認證后，接受方將立即回應一個確認Logon消息。發(fā)起方將把從接受方返回的Logon消息作為“一個會話已經(jīng)建立”的確認。消息同步LFIXT會話協(xié)議并不提供真正的會話層重傳機制，因此LFIXT會話協(xié)議的實現(xiàn)者作為會話的發(fā)起方，可通過會話重置消息（即ResetSeqNumFlag=Y的Logon消息）將會話雙方的消息序號重置，來完成會話層消息同步。LFIXT會話協(xié)議的實現(xiàn)者作為會話接受方，可以利用Logon消息中的NextExpectedMsgSeqNum來完成會話層消息同步。這種方式提供了對標準FIX會話協(xié)議的消息同步的兼容，具體機制參見“登錄消息處理”一節(jié)。消息交換在建立會話之后，會話雙方可以開始進行正常的消息交換。交換的消息包括“管理消息”和“應用消息”，本規(guī)范僅對管理消息進行描述。應用消息請參見具體的數(shù)據(jù)接口規(guī)范。注銷會話LFIXT會話的正常結(jié)束是通過連接雙方互相發(fā)送注銷消息（Logout），注銷時不需要進行消息缺口檢查。若結(jié)束時沒有收到回送的注銷消息（Logout），則把對方視作已注銷。除此之外的其它方式的會話結(jié)束視為非正常，并應按錯誤來處理。在結(jié)束會話之前，注銷消息（Logout）的發(fā)起方應該等待對方回送的注銷消息（Logout）。如果接收方在一定時間內(nèi)沒有答復，那么會話就可以立即中斷注銷不影響任何訂單的狀況。所有有效的訂單都可在注銷（Logout注銷不影響任何訂單的狀況。所有有效的訂單都可在注銷（Logout）之后執(zhí)行?；謴蚅FIXT會話協(xié)議的會話層恢復機制是為了與標準Fix會話協(xié)議兼容，不能作為真正的消息恢復機制使用，會話對端應通過應用層的消息恢復機制來獲得缺失的數(shù)據(jù)。LFIXT會話協(xié)議的實現(xiàn)者只在建立會話階段存在消息序號同步，在會話持續(xù)期間不提供真正的消息恢復，而是簡單地通過回應SeqReset-Reset消息來打發(fā)消息重傳請求。登錄消息處理LFIXT會話協(xié)議的實現(xiàn)者作為會話接收方,只需將本方NxtIn設置為發(fā)起方Logon消息的MsgSeqNum+1，NxtOut設置為發(fā)起方Logon消息中的NextExpectedMsgSeqNum(789)即可。會話接收方不需要檢查任何缺口，會話接收方也不會向發(fā)起方請求重傳任何消息。如果發(fā)送方?jīng)]有提供NextExpectedMsgSeqNum字段，則NxtOut設置為1.重傳請求消息處理作為LFIXT會話協(xié)議的實現(xiàn)者不會主動發(fā)送重傳請求，但可能收到標準的FIX會話協(xié)議實現(xiàn)者發(fā)送的重傳請求。當LFIXT會話協(xié)議的實現(xiàn)者收到重傳請求時，會使用SeqReset-Reset消息重置發(fā)送方序號，而不會提供歷史消息的重傳。序號重設消息處理LFIXT會話協(xié)議的實現(xiàn)者收到序號重設消息時，會根據(jù)序號重設消息中的NewSeqNo來重置本方NxtIn。

消息定義消息結(jié)構(gòu)每一條消息都由消息頭、消息體、消息尾組成。消息總是由標準消息頭開始，標準消息尾結(jié)束。消息頭會話雙方所有交換的消息具有如下標準的消息頭。每一個消息都由一個標準消息頭開始。消息頭定義了消息的類型，長度，目的地，順序號，起始點和時間等數(shù)據(jù)域，均不加密傳輸。其中有兩個域用于消息重發(fā)。當作為會話級事件的結(jié)果而重復傳送消息時，PossDupFlag被設置為Y，發(fā)送時沿用原來的消息序號；當[應用級]重新發(fā)送消息時，使用新的消息序號，并將PossResend設置為Y。接收者應按以下方法處理上述消息：PossDupFlag=Y：如果以前曾經(jīng)收到過帶有該消息序號的某條消息，則忽略本消息，如果不是，則按正常步驟處理。PossResend=Y：不附帶本標志地將消息傳遞給應用層，由其確定此前是否收到該消息Tag域名必須字段描述8BeginStringY起始串FIXT.1.1(總是不加密，必須是消息的第一個域)9BodyLengthY消息體長度(總是不加密，必須是消息的第二個域)35MsgTypeY消息類型(總是不加密，必須是消息的第三個域)49SenderCompIDY發(fā)送方代碼字符串(總是不加密)56TargetCompIDY接收方代碼字符串(總是不加密)34MsgSeqNumY消息序號，整數(shù)類型43PossDupFlagN會話層可能重傳標志，重復傳送時，作此標記97PossResendN應用層可能重發(fā)標志。LFIXT會話層協(xié)議的實現(xiàn)者不會在出向消息中主動設置本字段，對于入向消息中出現(xiàn)的本字段將簡單忽略52SendingTimeY發(fā)送時間，UTCTimestamp類型347MessageEncodingN消息中編碼域的字符編碼類型，缺省為GBK消息尾會話雙方所有交換的消息具有如下標準的消息尾。每一個消息（管理或應用消息）都用一個消息尾終止。消息尾可用于分隔多個消息，包含有3位數(shù)的校驗和值。Tag域名必須字段描述10CheckSumY校驗和，總是消息的最末域，總是不加密管理消息LFIXT會話協(xié)議支持標準FIX會話協(xié)議的所有管理消息，但不會主動發(fā)送所有管理消息。LFIXT會話協(xié)議分兩種模式：精簡模式和兼容模式，各自有不同的使用范圍。已知通信對手方為LFIXT會話協(xié)議實現(xiàn)者時，可以采用精簡模式，此時只需要支持如下消息的接收和發(fā)送處理。此時由于本方不會主動發(fā)送ResendRequest，因此根據(jù)協(xié)議也不會觸發(fā)對方回應SeqReset-Reset，因此不需要處理入向的SeqReset-Reset消息：管理消息類型來自對方本方發(fā)送Heartbeat是是Logon是是Reject是是Logout是是精簡模式：僅和LFIXT實現(xiàn)者通信時當需要和基于標準FIX引擎的對手方進行通信時，必須采用兼容模式。此時LFIXT會話協(xié)議實現(xiàn)者需要支持所有管理消息的接收，但仍然不需要支持所有管理消息的發(fā)送。兼容模式和精簡模式主要的區(qū)別只在于前者需要處理更多的入向管理消息。管理消息類型來自對方本方發(fā)送Heartbeat是是Logon是是TestRequest是否ResendRequest是否Reject是是SeqReset-Reset是是SeqReset-GapFill是否Logout是是兼容模式：和標準FIX會話協(xié)議實現(xiàn)者通信時一般而言，交易所端的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√√精簡模式LFIXT√協(xié)議兼容性矩陣Heartbeat心跳消息（MsgType=0）會話雙方使用Heartbeat消息來檢測當前使用的TCP連接的狀態(tài)，因此當一方處于數(shù)據(jù)發(fā)送空閑期時，需要定時發(fā)送Heartbeat消息以供檢測鏈接的健康度。接收方如果在兩倍的（[HeartBtInt]＋[合理傳輸時間]）內(nèi)沒有收到來自對方的心跳消息，就認為連接失敗，此時可以不發(fā)送Logout消息，立即關(guān)閉TCP連接。會話協(xié)議不會主動發(fā)送TestRequest消息，但LFIXT會話協(xié)議的實現(xiàn)者，為了與標準FIX會話協(xié)議的兼容，如果收到了TestRequest請求，會按標準FIX會話協(xié)議向發(fā)送方返回心跳響應。如果上層應用定義有應用層心跳信息，并以不低于HeartBtInt的間隔主動發(fā)送，則在事實上使得會話層心跳消息的發(fā)送條件永遠得不到滿足。在這種情況下，一方即使只收到應用層心跳消息，永遠也收不到來自對方的會話層心跳消息，也不構(gòu)成對本協(xié)議的違反。Tag域名必須字段描述StandardHeaderYMsgType=0112TestReqIDN字符串。如是對TestRequest響應而發(fā)送的心跳消息，則應包含本域。本域的內(nèi)容直接來自于觸發(fā)本心跳消息的TestRequest消息的內(nèi)容StandardTrailerYLogon登錄消息（MsgType=A）登錄消息應是請求建立一個會話的應用所發(fā)送的第一個消息。HeartBtInt(108)域用來聲明產(chǎn)生心跳的超時間隔（連接雙方使用相同的值）。連接雙方事先約定取值，由登錄發(fā)起方產(chǎn)生，并得到登錄接受方的確認響應。當收到登錄消息時，會話接受方將驗證發(fā)起方身份的合法性，并且發(fā)出登錄消息作為連接請求已被接受的確認。同樣，確認的登錄消息也可以被發(fā)起方用以驗證連接是與正確的對方建立的。會話接受方應在收到登錄消息之后，立即作好開始消息處理的準備。本標準規(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，但保存了入向消息10，此時應該填寫此字段為11，而非8。這一點在FIXT協(xié)議中并未明確規(guī)定，故本文檔對此予以特別限定。Tag域名必須字段描述StandardHeaderYMsgType=A98EncryptMethodY加密方法始終為0，即不加密108HeartBtIntY心跳間隔，單位是秒。雙方必須用同一個值141ResetSeqNumFlagN雙方序號重設回1的標志，布爾型789NextExpectedMsgSeqNumN接收方期望得到的下一條消息序號，可選。若不填寫，認為取值為1553UsernameN用戶名554PasswordN密碼1137DefaultApplVerIDY本次會話中使用的FIX消息的缺省版本。1407DefaultApplExtIDN本次會話中使用的FIX消息[在Tag1137基礎(chǔ)上]的缺省擴展包。1408DefaultCstmApplVerIDN本次會話中，F(xiàn)IX消息的缺省自定義應用版本。本標簽是對tag1137+tag1407的進一步約束。本字段必須填寫交易所發(fā)布的數(shù)據(jù)接口規(guī)范版本。如果接入方不提供該字段，接收方將不會允許接入方接入，并會通過Logout消息終止該會話。StandardTrailerYTestRequest測試請求消息（MsgType=1）測試請求消息能強制對方發(fā)出心跳消息。會話協(xié)議不會主動發(fā)送該消息。測試請求消息的作用是檢查對方消息序號和檢查通信線路的狀況。對方用帶有測試請求標識符（TestReqID）的心跳作應答。LFIXT協(xié)議的實現(xiàn)方不會主動發(fā)送任何TestRequest消息Tag域名必須注釋StandardHeaderYMsgType=1112TestReqIDN測試請求標識符StandardTrailerYResend重發(fā)請求消息（MsgType=2）重發(fā)請求消息由接收方發(fā)出，目的是向發(fā)送方申請某些消息重復發(fā)送。LFIXT會話協(xié)議不會主動發(fā)送該消息。重發(fā)請求消息有以下幾種表示方式：請求重發(fā)一條消息：BeginSeqNo=EndSeqNo請求重發(fā)某個范圍內(nèi)的消息：BeginSeqNo=該范圍中的第1條消息序號，EndSeqNo=該范圍中的最后一條消息序號。注意請求重發(fā)一條消息只是本形式的特例。請求重發(fā)某一特定消息之后的所有的消息：BeginSeqNo=該范圍中的第1條消息，EndSeqNo=0（代表無窮大）LFIXT會話協(xié)議的實現(xiàn)者作為本消息的接收方時，只會通過SeqReset-Reset消息響應標準FIX會話協(xié)議實現(xiàn)者發(fā)送的重傳請求消息。Tag域名必須注釋StandardHeaderYMsgType=27BeginSeqNoY起始消息序號16EndSeqNoY結(jié)束消息序號StandardTrailerYReject會話拒絕消息（MsgType=3）當接收方收到一條消息，由于違反了會話層規(guī)則而不能適當?shù)靥幚碓撓r，應該發(fā)出Reject（拒絕）消息。發(fā)出Reject

消息可能是合適的一個例子是：收到了一條成功經(jīng)過解碼、校驗和檢查及BodyLength檢查的消息，但該消息帶有不合法的基本數(shù)據(jù)（比如：MsgType=&）。規(guī)則要求：只要可能，消息應盡可能被轉(zhuǎn)發(fā)給交易程序并通過業(yè)務層拒絕（而非會話層的Reject消息）來響應。若收到一條滿足會話層規(guī)則的應用層消息，它必須在業(yè)務消息的層面被處理。若此處理過程發(fā)現(xiàn)了規(guī)則的違反，則應當產(chǎn)生一條業(yè)務層拒絕消息。許多業(yè)務層消息有特有的“拒絕”消息，應該使用這些消息。全部其他情況都可以通過“業(yè)務消息拒絕消息”進行拒絕。注意，即使收到了業(yè)務消息，且滿足會話層規(guī)則，但當此消息不能被送達業(yè)務層處理系統(tǒng)的時候，也應該發(fā)送一條BusinessRejectReason=“應用此刻不存在”的“業(yè)務消息拒絕”消息。被拒絕的消息應該被記錄日志，且入向序號應該增加。和標準FIX會話協(xié)議不同之處在于：在LFIXT會話協(xié)議中，如果收到的消息是混亂的(garbled)，或者說：不能被解析或不能通過數(shù)據(jù)完整性檢查時，應當記錄日志后回送Logout消息并立刻斷開連接（在標準FIX會話協(xié)議中建議忽略并丟棄本消息，以期望后續(xù)收到的正確格式的消息能觸發(fā)一個消息缺口，從而能通過重傳請求再度拿回這條混亂的消息）。同時也需要注意：這并非會話層Reject消息的使用場景。產(chǎn)生和收到Reject消息，意味著出現(xiàn)了嚴重錯誤，可能發(fā)送方或接收方的應用存在邏輯錯誤。如果發(fā)送方應用選擇重新發(fā)送被拒絕的消息，應當使用新的消息序號并設置PossResend=Y。因為PossResend=Y的語義是可能的應用層重發(fā)，因此這里被重新發(fā)送的一定是指應用層消息而非管理消息。只要有可能，強烈推薦在本消息的Text字段中描述引起錯誤的原因。當收到Reject消息本身時，建議記錄日志，然后調(diào)整入向序號。Tag域名必需說明StandardHeaderYMsgType=345RefSeqNumY關(guān)聯(lián)消息的序號，即被拒絕消息(對方發(fā)送且己方收到)的序號。371RefTagIDN相關(guān)錯誤消息中，出現(xiàn)錯誤的FIX域號372RefMsgTypeN相關(guān)錯誤消息的MsgType373SessionRejectReasonN會話拒絕原因編號58TextN文本，可解釋拒絕的原因StandardTrailerY會話拒絕原因(SessionRejectReason)0=無效域號1=該消息中必須的域丟失2=該消息中出現(xiàn)未曾定義的域3=未定義的域號4=聲明了域，但未賦值5=此域的值錯誤（范圍溢出）6=取值格式錯誤7=解密錯誤8=簽名錯誤9=CompID錯誤10=發(fā)送時間精度錯誤11=無效的MsgType12=XML驗證錯誤13=域多次出現(xiàn)（非重復組）14=有序的域出現(xiàn)次序錯誤15=重復組中，域次序錯誤16=重復組中，NumInGroup錯誤17=非data數(shù)據(jù)域中，出現(xiàn)域界定符<SOH>99=其他。注意可能存在其他的會話層規(guī)則違反，此時，“會話拒絕原因”99可以被使用，進一步的信息應當包括在Text字段中。會話拒絕場景SeqReset序號重設消息（MsgType=4）序號重設消息由發(fā)送方發(fā)出，用于告知接收方下一個消息的消息序號。序號重設消息有兩種模式：序號重設-缺口填補（SeqReset-GapFill）；序號重設-重設（SeqReset-Reset）。在LFIXT會話協(xié)議中，只使用SeqReset-Reset消息回應ResendRequest消息，此SeqReset-Reset消息的MsgSeqNum按標準FIX協(xié)議規(guī)定可以任意填寫且接收方不會檢查，在LFIXT中規(guī)定固定填寫1，其中的NewSeqNo則建議填寫為max{ResendRequest消息的EndSeqNo字段值，本方NxtOut值}。序號重設只能增加消息序號。如果收到的序號重設消息試圖使下一個預期的消息序號變小，那么此消息應被拒絕接受，并被視作為嚴重錯誤。在LFIXT會話協(xié)議中，雖然不會主動發(fā)起重傳請求，但仍然有可能收到標準FIX協(xié)議的對手方主動發(fā)出的SeqReset類消息。當收到的序號重設消息為SeqReset-GapFill消息時，必須確保NewSeqNo必須大于等于SeqReset-GapFill消息本身的MsgSeqNum+1且不允許NewSeqNo>NxtIn，此時本方NxtIn保持不變；否則，被視為嚴重錯誤。當收到SeqReset-Reset消息時，則需要忽略MsgSeqNum的檢查，同時令本方NxtIn=NewSeqNo。Tag域名必須注釋StandardHeaderYMsgType=4123GapFillFlagN缺口填補標志。布爾型。“Y”表明是GapFill模式；“N”或不存在本域，表明是Reset模式。36NewSeqNoY新消息序號StandardTrailerYLogout注銷消息（MsgType=5）注銷消息是發(fā)起或確認會話終止的消息。未經(jīng)注銷消息的交換而斷開連接，一律視為非正常的斷開。在最后終止會話之前，注銷的發(fā)起人應該等待連接對方確認注銷消息。如果連接對方?jīng)]有在適當?shù)臅r間間隔里作回應，那么會話就可以終止。注銷發(fā)起人在發(fā)送注銷消息之后不應發(fā)送任何消息，除非接收到連接對方發(fā)出的重傳請求消息。何時發(fā)送Logout，何時直接斷開一般而言，在關(guān)閉連接前推薦的做法是回送一條Logout消息以利于對端診斷連接斷開的原因。但此處可有一些例外：1.若收到的登錄報文中，SenderCompID,TargetCompID或者會話發(fā)起方的IP地址不合法，推薦做法是會話立即終止，不發(fā)送任何Logout消息。原因是此種登錄嘗試很可能屬于未被授權(quán)的系統(tǒng)入侵行為，因此不應當回送Logout消息以泄露FIX版本、合法SenderCompID、TargetCompID等信息。2.在標準FIXT協(xié)議中，在收到登錄請求時若在同一個FIX引擎若已存在一個合法的相同KEY的會話，則標準FIX引擎將直接斷開后來的登錄請求所欲發(fā)起的會話。由于任何時刻總是存在網(wǎng)絡中斷的可能，因此LFIXT協(xié)議的任何參與方都應該對于沒有收到對方的Logout消息但底層TCP連接卻已關(guān)閉的情況做好準備。在斷開連接前回送Logout消息是推薦行為，但非必須。在此簡要總結(jié)一下：對于收到報文中的各類異常接收方通常處理的原則。TCP通信異常/潛在的惡意攻擊推薦處理方式是直接斷開TCP連接。由于在任何情況下通信參與者都必須能夠處理TCP連接的中斷，因此這也是缺省處理辦法。對于同一個TCP連接上，第一個收到的報文不是正確的Logon報文，或者在已經(jīng)Logon成功的TCP連接上又收到一個普通的Logon消息，視作惡意攻擊，直接斷開?；靵y的報文、入向消息序號出現(xiàn)缺口推薦處理方式是回送Logout消息，然后斷開TCP連接報文不混亂，但不滿足會話層規(guī)則推薦處理方式是發(fā)送Reject拒絕此消息，會話繼續(xù)報文不混亂，滿足會話層規(guī)則交給應用層去處理。如果應用層發(fā)現(xiàn)報文違反了應用層規(guī)則，回送應用層拒絕消息，會話繼續(xù)Tag域名必須字段描述StandardHeaderYMsgType=51409SessionStatusNLogout時的會話狀態(tài)。根據(jù)FIX協(xié)議有如下取值：0=會話活躍 1=會話口令已更改2=將過期的會話口令3=新會話口令不符合規(guī)范 4= 會話退登完成5=不合法的用戶名或口令 6=賬戶鎖定 7=當前時間不允許登錄 8= 口令過期9=收到的MsgSeqNum(34)太小10=收到的NextExpectedMsgSeqNum(789)太大.100及100以上的數(shù)字可供用戶在雙邊認可的情況下自定義58TextN文本。注銷原因的進一步補充說明。StandardTrailerY數(shù)據(jù)字典數(shù)據(jù)類型數(shù)據(jù)類型類型定義說明SeqNumN18消息序號正整數(shù)BooleanC1‘Y’=Yes/True,‘N’=False/NoLengthN9長度表示字節(jié)為單位的數(shù)據(jù)長度，非負數(shù)UTCTimeStampC21UTC時間戳，注意，F(xiàn)IX協(xié)議允許使用YYYYMMDD-HH:mm:SS，YYYY=0000-9999,MM=01-12,DD=01-31,HH=00-23,mm=00-59,SS=00-60（秒）,或YYYYMMDD-HH:mm:SS.sss(毫秒)，YYYY=0000-9999,MM=01-12,DD=01-31,HH=00-23,mm=00-59,SS=00-60（秒）,sss=000-999（毫秒）之中的任何一種格式LocalTimeStampC21本地時間戳YYYYMMDD-HH:mm:SS.sss(毫秒)，YYYY=0000-9999,MM=01-12,DD=01-31,HH=00-23,mm=00-59,SS=00-60（秒）,sss=000-999（毫秒）NumInGroupN9重復數(shù)表示重復組的項數(shù)，正數(shù)注：除非特別聲明，浮點數(shù)類型均有正負，類型定義Nx(y)中，x表示整數(shù)與小數(shù)總計位數(shù)的最大值，不包括小數(shù)點，y表示固定的小數(shù)位數(shù)。類型定義Cx中，x表示字符串的最大長度。會話層域定義Tag域名類型說明7BeginSeqNoSeqNum起始消息序號8BeginStringC16起始串固定為FIXT.1.19BodyLengthLength消息體長度10CheckSumC3校驗和不加密，必須是最后一個域校驗算法參見STEP協(xié)議16EndSeqNoSeqNum結(jié)束消息序號34MsgSeqNumSeqNum消息序號，由1開始35MsgTypeC16消息類型36NewSeqNoSeqNum新消息序號43PossDupFlagBoolean指示該消息序號的消息可能重復發(fā)送，取值：=Y:可能重復=N:首次發(fā)送49SenderCompIDC32發(fā)送方代碼52SendingTimeUTCTimestamp消息發(fā)送時間，UTCTimestamp類型56TargetCompIDC32接收方代碼58TextC1024文本97PossResendBoolean可能重發(fā)標志指示該消息可能發(fā)送過（使用不同的消息序號），取值：=Y:可能重發(fā)=N:首次發(fā)送98EncryptMethodN8加密方法=0:即不加密108HeartBtIntN8心跳監(jiān)測的時間間隔為系統(tǒng)設定值,以秒為單位112TestReqIDC32測試請求標識符141ResetSeqNumFlagBoolean序號重設標志123GapFillFlagBoolean缺口填補標志用于序號重設消息，指示是否填補缺口，取值：=Y:序號重設-缺口填補消息，消息序號域有效=N或不存在序號重設-重設消息，消息序號域無效347MessageEncodingC16消息中編碼域的字符編碼類型缺省是GBK371RefTagIDN9相關(guān)錯誤消息中，出現(xiàn)錯誤的FIX域號372RefMsgTypeC16相關(guān)錯誤消息的MsgType373SessionRejectReasonN9會話拒絕原因編號，無符號整數(shù)383MaxMessageSizeLength最大消息長度，單條消息的最大字節(jié)數(shù)。該字段暫未啟用553UserNameC32用戶名554PasswordC32密碼789NextExpectedMsgSeqNumSeqNum接收方期望得到的下一條消息序號1137DefaultApplVerIDC8本次會話中使用的FIX消息的缺省版本。若取值為'9'，意思是'FIX50SP2'1407DefaultApplExtIDN8本次會話中使用的FIX消息[在Tag1137基礎(chǔ)上]的缺省擴展包。若取值'124'，意思是'EP124'1408DefaultCstmApplVerIDC32本次會話中，F(xiàn)IX消息的缺省自定義應用版本。本標簽是對tag1137+tag1407的進一步約束。本字段填寫交易所發(fā)布的數(shù)據(jù)協(xié)議版本。建議的格式是：STEP版本號_市場代碼_市場內(nèi)部唯一的協(xié)議版本號。市場代碼是SH時，代表上海證券交易所；是SZ時，代表深圳證券交易所。市場內(nèi)部唯一的協(xié)議版本號由各市場自行分配。1409SessionStatusN4本字段填寫退登時的會話狀態(tài)

（登錄場景）正常登錄場景一LFIX作為登錄發(fā)起方——Client，LFIX作為登錄接受方——Server，日間正常登錄。場景開始時，TCP連接剛建立時，Client的NxtOut=1,NxtIn=1，Server的NxtOut=1,NxtIn=1。正常登錄場景一FIX會話建立后，Client的NxtOut=2,NxtIn=2，Server的NxtOut=2,NxtIn=2。正常登錄場景二標準FIX作為登錄發(fā)起方——Client，LFIX作為登錄接受方——Server，日間非首次正常登錄，且Client不設置ResetSeqNumFlag，設置NextExpectedMsgSeqNum為其在前一次連接斷開時的NxtIn。場景開始時，TCP連接剛建立后，Client的NxtOut=100,NxtIn=189，Server的NxtOut=1,NxtIn=1。在此之前，Server曾經(jīng)向Client發(fā)送過MsgSeqNum為189，190的業(yè)務消息，但因為通信故障，Client沒有收到，所以Client端保存的NxtIn仍然是189，而非191。正常登錄場景二FIX會話建立后，Client的NxtOut=101,NxtIn=190，Server的NxtOut=190,NxtIn=101。注意兩次TCP連接上Server發(fā)送給Client的MsgSeqNum=189的消息并不相同，但因為Client沒有保存之前收到的MsgSeqNum=189的業(yè)務消息，所以第二次收到MsgSeqNum=189的Logon應答消息也不會發(fā)現(xiàn)存在不一致。正常登錄場景三為了說明在標準FIX協(xié)議中，NextExpectedMsgSeqNum相關(guān)的自動缺口填補的原理，撰寫此場景。本場景中，通信雙方都遵循標準FIX協(xié)議。在場景開始的時候，Server的NxtOut是250，NxtIn是200；由于Server和Client之間出現(xiàn)了網(wǎng)絡中斷，因此Client只收到了序號為247（含）以前的來自Server的消息,其NxtOut是200，NxtIn是248。Server收到的來自Client的登錄消息中，NextExpectedMsgSeqNum是248，但Server端內(nèi)部下一個發(fā)送的應該是LOGON消息，必須使用新的序號250。但Server端也知道Client端出現(xiàn)了消息缺口，且根據(jù)協(xié)議Client不會為此缺口發(fā)送ResendRequest消息，而是需要Server端主動推送缺口部分的消息。因此Server端馬上重復傳送業(yè)務消息248，業(yè)務消息249，并用SeqReset-GapFill消息替代消息250——Logon消息，之后就可以開始正常傳送業(yè)務消息251。正常登錄場景三異常登錄場景一標準FIX作為登錄發(fā)起方——Client，LFIX作為登錄接受方——Server，日間非首次正常登錄，且Client不設置ResetSeqNumFlag，也沒有設置NextExpectedMsgSeqNum為其在前一次連接斷開時的NxtIn。場景開始時，TCP連接剛建立后，Client的NxtOut=100,NxtIn=189，Server的NxtOut=1,NxtIn=1。異常登錄場景一由于標準FIX客戶端沒有正確設置NextExpectedMsgSeqNum，收到的LOGON響應報文的MsgSeqNum是1，小于預期的189，因此標準FIX客戶端認為出現(xiàn)了嚴重錯誤，在發(fā)送LOGOUT后斷開連接。異常登錄場景二LFIX作為登錄發(fā)起方——Client，LFIX作為登錄接受方——Server，其余情況同本節(jié)場景一，唯一的區(qū)別在于Client在LOGON消息中提供的用戶名和口令非法。異常登錄場景二

（注銷場景）正常注銷場景下圖顯示注銷會話的場景，申請注銷后，服務方回送注銷消息確認斷開會話。正常注銷場景

（處理重傳請求場景）處理重傳請求場景一下圖中，Client是標準FIX引擎，Server是LFIX引擎，且Client因為某種特殊的原因，比如雖然收到但因為自身錯誤而沒有將消息98和99保留下來，但保存了消息100。處理重傳請求一處理重傳請求場景二和本節(jié)場景一前面部分都相同，但區(qū)別在于Client沒有來得及發(fā)出ResendRequest，網(wǎng)絡連接就斷了，因此需要重新登錄并后續(xù)發(fā)送ResendRequest補缺口。在登錄時使用的NextExpectedMsgSeqNum是根據(jù)登錄時已知的最大消息序號確定，而非根據(jù)全部缺口消息中最小的序號來確定。處理重傳請求二（處理心跳和測試請求）處理心跳和測試請求下圖是心跳和測試請求的場景，連接雙方的空閑持續(xù)在經(jīng)過一個約定的時間間隔后，連接雙方根據(jù)規(guī)則都可以發(fā)送心跳。標準FIX協(xié)議的實現(xiàn)者可以不受限制地主動發(fā)起測試請求。下圖中的Server是LFIX協(xié)議的實現(xiàn)者，不會主動發(fā)起測試請求。處理心跳和測試請求（處理會話拒絕）處理會話拒絕LFIX會話協(xié)議中，收到會話拒絕后應該記錄日志，調(diào)整入向消息序號。下圖中，Server是LFIX引擎，Client是標準的FIX引擎。處理會話拒絕

（計算校驗和）計算校驗和以下為計算校驗和的代碼段：char*GenerateCheckSum(char*buf,longbufLen){ staticchartmpBuf[4]; longidx; unsignedintcks; for(idx=0L,cks=0;idx<bufLen;cks+=(unsignedint)buf[idx++]); sprintf(tmpBuf,“%03d”,(unsignedint)(cks%256)); return(tmpBuf); }

（狀態(tài)轉(zhuǎn)換參考圖）LFIXT會話協(xié)議狀態(tài)轉(zhuǎn)換參考圖此圖可以作為LFIX引擎實現(xiàn)的參考，但不能替代真實LFIX引擎開發(fā)的設計文檔。若和正文有不一致，一律以協(xié)議正文為準。

（實現(xiàn)參考）LFIXT會話協(xié)議實現(xiàn)參考本參考若和協(xié)議正文不一致，一律以協(xié)議正文為準。本參考按所收到的不同消息分別說明所需進行的最基本校驗，以及在通過完整校驗后的最基本處理。