輕量級(jí)STEP會(huì)話層接口規(guī)范

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

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

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

目錄TOC\o"1-4"\h\z\u一、 范圍 1二、 會(huì)話機(jī)制 22.1 術(shù)語(yǔ)和定義 22.1.1 會(huì)話層重傳 22.1.2 應(yīng)用層重傳 22.1.3 NxtIn和NxtOut 22.1.4 會(huì)話發(fā)起方和接受方 22.1.5 消息序號(hào) 32.1.6 心跳 42.1.7 有序消息處理 42.1.8 可能的消息重復(fù)傳送 42.1.9 可能的消息重新發(fā)送 52.1.10 消息完整性 52.1.11 混亂的消息(garbledmessage) 52.1.12 消息確認(rèn) 62.1.13 加密 62.2 會(huì)話管理 62.2.1 建立會(huì)話 6 建立連接 6 身份認(rèn)證 6 消息同步 72.2.2 消息交換 72.2.3 注銷會(huì)話 72.3 恢復(fù) 72.3.1 登錄消息處理 72.3.2 重傳請(qǐng)求消息處理 72.3.3 序號(hào)重設(shè)消息處理 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測(cè)試請(qǐng)求消息（MsgType=1） 133.2.4 Resend重發(fā)請(qǐng)求消息（MsgType=2） 133.2.5 Reject會(huì)話拒絕消息（MsgType=3） 143.2.6 SeqReset序號(hào)重設(shè)消息（MsgType=4） 163.2.7 Logout注銷消息（MsgType=5） 16四、 數(shù)據(jù)字典 184.1 數(shù)據(jù)類型 184.2 會(huì)話層域定義 19附錄A 21（登錄場(chǎng)景） 21正常登錄場(chǎng)景一 21正常登錄場(chǎng)景二 21正常登錄場(chǎng)景三 22異常登錄場(chǎng)景一 24異常登錄場(chǎng)景二 24附錄B 26（注銷場(chǎng)景） 26正常注銷場(chǎng)景 26附錄C 27（處理重傳請(qǐng)求場(chǎng)景） 27處理重傳請(qǐng)求場(chǎng)景一 27處理重傳請(qǐng)求場(chǎng)景二 28附錄D 30（處理心跳和測(cè)試請(qǐng)求） 30處理心跳和測(cè)試請(qǐng)求 30附錄E 31（處理會(huì)話拒絕） 31處理會(huì)話拒絕 31附錄F 32（計(jì)算校驗(yàn)和） 32計(jì)算校驗(yàn)和 32附錄G 33（狀態(tài)轉(zhuǎn)換參考圖） 33LFIXT會(huì)話協(xié)議狀態(tài)轉(zhuǎn)換參考圖 33附錄H 34（實(shí)現(xiàn)參考） 34LFIXT會(huì)話協(xié)議實(shí)現(xiàn)參考 341. Logon消息 342. Heartbeat消息 353. TestRequest消息 354. ResendRequest消息 355. SeqReset-Reset消息 366. SeqReset-GapFill消息 367. Reject消息 378. Logout消息 379. 應(yīng)用消息 37Version1.00 輕量級(jí)STEP會(huì)話層接口規(guī)范 2015-08-28第38頁(yè)共=NUMPAGES43-538頁(yè)輕量級(jí)STEP會(huì)話協(xié)議接口規(guī)范范圍本標(biāo)準(zhǔn)對(duì)STEP會(huì)話層協(xié)議（即FIX會(huì)話層協(xié)議FIXT1.1版本）進(jìn)行了裁剪和改造,確立了一個(gè)基于TCP的輕量化STEP會(huì)話層協(xié)議（記作：LFIXT會(huì)話層協(xié)議），同時(shí)LFIXT標(biāo)準(zhǔn)仍然可以保持和標(biāo)準(zhǔn)STEP/FIX會(huì)話層協(xié)議的互操作性。本標(biāo)準(zhǔn)規(guī)定了LFIXT會(huì)話層協(xié)議使用的會(huì)話機(jī)制、消息格式、安全與加密、數(shù)據(jù)完整性、擴(kuò)展方式、消息定義、數(shù)據(jù)字典等內(nèi)容。如無(wú)特別說(shuō)明，本標(biāo)準(zhǔn)中提及的接收方、發(fā)送方等通信參與方均特指遵循LFIXT會(huì)話層協(xié)議而實(shí)現(xiàn)的應(yīng)用程序或模塊。由于遵循本協(xié)議開(kāi)發(fā)的程序或模塊將可以同標(biāo)準(zhǔn)FIX引擎進(jìn)行正常通信，因此若通信的一方是標(biāo)準(zhǔn)的FIX引擎，則除本文特別制訂的少數(shù)額外約束外，其實(shí)現(xiàn)不受本文檔約束。

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

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

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

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

（注銷場(chǎng)景）正常注銷場(chǎng)景下圖顯示注銷會(huì)話的場(chǎng)景，申請(qǐng)注銷后，服務(wù)方回送注銷消息確認(rèn)斷開(kāi)會(huì)話。正常注銷場(chǎng)景

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

（計(jì)算校驗(yàn)和）計(jì)算校驗(yàn)和以下為計(jì)算校驗(yàn)和的代碼段：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會(huì)話協(xié)議狀態(tài)轉(zhuǎn)換參考圖此圖可以作為L(zhǎng)FIX引擎實(shí)現(xiàn)的參考，但不能替代真實(shí)LFIX引擎開(kāi)發(fā)的設(shè)計(jì)文檔。若和正文有不一致，一律以協(xié)議正文為準(zhǔn)。

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