金融信息交換協議(FIX)

隨着網絡的使用，目前所有大型的金融機構都已經實現了自動化和數字化。當中肯定少不了互聯網的加入，那麼在這當中，我們主要介紹一下FIX協議。它是由國際FIX協會組織提供的一個開放式協議，目的是推動國際貿易電子化的進程，在各類參與者之間，包括投資經理、經紀人，買方、賣方建立起實時的電子化通訊協議。Fix協議的目標是把各類證券金融業務需求流程格式化，使之成爲一個個可用計算機語言描述的功能流程，並在每個業務功能接口上統一交換格式，方便各個功能模塊的連接。

FIX協議結構

當前,FIX協議的格式存在着兩種結構:"標記（Tag）〉=〈值（Value）"域結構和 FIXML 結構。下面針對域結構模式對FIX協議的組成，連接建立、信息交換方法等進行簡要說明，以便於瞭解FIX協議的概念。

FIX信息格式

(1) 信息格式

一條FIX協議信息的基本格式是：

《標準頭》+《信息正文域》+《標準尾》

每條信息都是由一系列帶有〈標記（Tag）〉=〈值（Value）〉的域組成的。在每個域之間通過"< >"分開。除了一些特殊規定外，信息中的域可按照任意順序排列。所有域在都以"定界符"（#001；0x01H,文檔中寫爲<SOH>）表示終止。

(2) 標準的信息標題

每條命令或應用信息都有一個標準的標題。標題表明了信息類型、長席、目的地、序號、起始點和時間。

(3) 標準的信息尾部

所有的信息，無論是命令類的，還是應用類的，以一個標準結尾終止。尾部被用來把信息分離，幷包括含有3位數的"檢驗和"值。

(4) 數據類型

各域所使用的數據類型包括以下幾種：整數、浮點數、布爾數、字符串、多元值串、貨幣、交易所字符串域、國際標準時時間戳、國際標準時時間、本地市場日期等。

(5) 數據完整性

信息數據內容是否完整可以通過"檢查信息長度"和字符的簡單"檢驗和"兩個方法進行檢查。

(6) 加密

爲了保證信息安全，對傳遞的信息需要加密，加密方法的選擇由傳送中的有關雙方協議而定。任何域都可被加密並被添加於"密碼"的域內，不過，被確信可被清楚識別的域必須以非加密方式進行傳送，這些公開的域（非加密）能在密碼的域內被重複以完整地檢驗公開的數據。

FIX協議的連接建立

建立一個FIX連接包括：電信層面連接的創立、經由接收方對發起方的確認、信息同步三個步驟。

FIX信息交換過程的實施

FIX信息交換過程的定義爲：

在兩方之間，一個連續的序號系列範圍內的雙向定單信息傳送。每條信息都有獨特的序號識別。在每次FIX交換過程開始時，就是序號的開始，首先從1開始，並依次增加直至貫穿整個交換過程。當在FIX交換過程中重新進行連接的時候，監控序號將能使各方能識別錯過的信息，並能做出反應，來使應用方達到一致地同步。

在整個信息沒有被激活的時期裏，信息交換方將在有規則的時間間隔裏產生"心跳信息"。通過"心跳信息"可監控通信連接的狀況，識別進入的序號缺口，並確認是否接收到最後的信息串。"心跳間隔"是由交換過程發起人使用"心跳指令"域在"登錄"信息中宣佈的。

當信息交換連接的任何一方在"心跳指令"的時間內都不發送任何數據的時候,"心跳信息"將被傳送。當連接的任何一方在"心跳指令"+"合理的傳輸時間"的時間內仍沒有收到"心跳信息"，那麼，可以認爲此次連接失敗，而且需開始實施修正操作。如果"心跳指令"被設置爲零，將不會生成定期的"心跳信息"。

FIX的連接註銷

信息交換過程的正常結束是通過雙方互相發送"註銷"（Logout）信息來完成。"註銷"信息是開始或確認一個FIX過程終止的信息，未經"註銷"信息的交換而斷開的連接是反常情況，並應按錯誤來處理。

FIX通信協議的應用

針對國內的證券交易模式的分佈式結構，即證券公司的各營業部、分支機構數據分佈存放，各自獨立，直接與交易所聯繫，國內券商正在探討並逐步推出集中交易系統,集中交易系統可以帶來集中風險控制、提高系統效率等優勢，可以在集中交易系統的構建、規劃過程中，借鑑應用FIX標準化協議，構建具有數據層、核心業務層+FIX通信層、應用層的廣義三層結構。用FIX金融信息交換協議包取代過去的文件或通信包交換的模式。

在FIX協議的應用過程中應該注意到，由於亞洲地區的證券交易方式與FIX協議的主導地區美洲和歐洲國家有一定的差異，因此直接利用現有的FIX協議，特別是證券業務流程上的規範有一定的困難。

例如FIX協議在日本證券行業的應用就遇到了信息定義內容和信息流程順序上的問題。因此國內的FIX的開展首先要關注FIX及其在中國的適用性，吸收其它市場的經驗，將國內外不同的交易程序加以比較，分析協議的使用方法以及協議使用環境，結合國內證券市場的實際，使得該項協議既能成爲一項標準又能爲中國證券市場服務，爲中國證券交易的標準化過程中發揮作用。

 

1 簡介

FIX會話協議與選擇用於電子數據傳遞的物理介質（銅纜，光纖，衛星傳輸等）及傳輸協議規範（X.25，同步，TCP/IP等）無關。它提供了一個消息傳遞的可靠數據流。直到2006年10月，FIX會話協議與FIX應用協議一道，爲用戶提供了一個可靠的傳輸FIX應用消息的傳輸機制。

FIX會話層與數據傳輸相關，而FIX應用層則定義了商業相關的數據內容。

2006年10月，FPL’s Global Techenical Committee 引入了一個新的框架，將FIX會話層協議從FIX應用層協議分離開來。這就使應用協議消息可以使用任何適的會話傳輸技術進行傳送，而FIX會話層協議是這些可選的協議中的一個。在新的框架下，GTC引入了一個新的別名，之後FIX會話層協議版本爲FIXT.x.y，第一個版本爲FIXT1.1。

2 FIXML及其它基於XML數據的傳輸

儘管FIX會話協議的標準頭（Standard Header），標準尾部（Standard Trailer）和管理消息是基於“tag=value”語法的，但它能夠支持傳輸FIXML及其它基於XML的數據。FIXML及其它XML數據被夾在FIX標準頭與FIX標準尾部中間，並通過標準頭的XmlDataLen域指定其內容長度，XmlData域包含其具體的數據。這樣，FIX引擎可以通過多年使用的，可靠的，實時地異步傳輸機制傳送FIXML及其它XML數據。當MsgType域值爲’n’時，代表傳輸的數據爲FIX未在MsgType中定義的XML數據。

3 FIX消息傳送

3.1 Sequence Numbers 序列編號

所有的FIX消息都由一個唯一的序列號進行標示。序列號在每一個FIX會話開始時被初始化爲1，並在整個會話期間遞增。監控序列號可以使會話參與者識別和處理丟失的消息，當在一個FIX會話中重新連接時能夠優雅地進行應用程序同步。

每個會話將建立一組互不依賴的接受和發送序列。會話參與者將維護一個賦予發送消息的序列和一個監控接受消息的消息塊間隙序列號。

3.2 Heartbeats 心跳信號

在消息交互期間，FIX應用程序將週期性產生Heartbeat心跳消息。該心跳消息可以監控通信鏈路狀態及識別接受序列號間隙。發送Heartbeat的週期間隔由會話發起者使用在Logon消息中HeartBtInt域進行定義。Heartbeat心跳消息的時間間隔應當在每一個消息發送後復位，即發送一個消息後，在間隔給定的時間內無其它消息發送則發送一個Heartbeat心跳消息。HeartBtInt的值應當被會話雙方認同，由會話發起方定義並由會話接收者通過Logon消息進行確認。同一個HeartBtInt被會話雙方——登錄的發起者和登錄的接受者共同使用。

3.3 Ordered Message Processing 消息序列處理

FIX協議假設消息在所有參與者間完全按照順序進行傳輸。協議的實現者在設計消息間隙填充處理時應當考慮這個假設。有兩種方式處理消息間隙。每一個都要求所有的消息時最後一個接收消息的後續消息或在維護一個所有新消息有序序列時，請求特定丟失消息。比如：接收方丟失了5個消息塊中的第二個，程序能忽略第3到第5個消息，產生一個對消息2到消息5的重傳請求，或者從消息2到無窮大消息編號的重傳請求。另外的方式是暫時存儲消息3到消息5，僅要求重傳消息2。對於這兩種方式，消息3到消息5都不應該先於消息2進行處理。

3.4 Possible Duplicates 可能的複製

當一個FIX引擎對一個消息是否成功地被指定的目標接收或者當對一個重傳請求進行響應時，將會產生一個可能的消息複製。這個消息將用同樣的序列進行重新傳送，此時在頭部的PossDupFlag域將會被設置爲‘Y’。接收端程序負責處理該重發消息，可以作爲一個新消息進行處理，或者根據實際情況忽略該消息。所有重傳請求的響應消息都將包含其值爲‘Y’的PossDupFlag域。沒有PossDupFlag域或者PossDupFlag域爲‘N’的消息應被當作初始傳送消息。注意，一個PossDupFlag值爲‘Y’的重傳消息需要重新計算其CheckSum值。一個可能的複製消息裏發生變化的域包括：CheckSum，OrigSendingTime，SendingTime，BodyLength和PossDupFlag。加密相關域（SecureDataLen和SecureData）也必須被重新構造。

3.5 Possible Resends 可能的重傳

模糊的應用層消息可能隨同PossResend標誌被重傳。當一個指令沒有在規定時間長度內進行確認或者終端用戶掛起該指令沒有進行傳送時這種方法非常有用。接收程序必須識別此標誌，並質疑其內部域以確定該指令是否在之前已經被接收過。注意，可能的重傳消息將包含與原始消息相同的數據體，但包含PossResend標誌和一個新的序列號。此外，CheckSum和與加密相關的域值需要重構。

3.6 Data Integrity 數據完整性

消息數據內容的完整性可以參用兩種方式來驗證：消息長度和效驗碼檢查。

程序通過計算BodyLength域到（幷包含）在CheckSum標記（“10=”）後的分界符的字符數與在BodyLength中標示的消息長度進行比較來完成完整性效驗。

ChekSum完整性檢查，通過計算從域“8=” 中“8”開始，包括緊跟在CheckSum標記域的分界符<SOH>每個字符的2進制和同CheckSum進行比較得到。

3.7 Message Acknowledgment 消息確認

FIX會話協議基於一個優化模型。普通的數據傳送（無單個消息確認）被假設爲通過消息序列間隙進行錯誤識別。每個消息由一個唯一的序列號進行標示。接收端應用程序負責監控接收消息序列號以識別消息間隙併產生重傳請求。

FIX協議不支持單個消息的確認。然而，多數應用消息需要顯示地應用層接收和拒絕。

3.8 Encryption 加密

敏感數據在公衆網絡上的傳輸建議採用數據加密技術來掩飾應用消息。

加密算法由連接雙方共同協商。

一個消息的任何一個域可以被加密並放在SecureData域中。然而，一些顯示的標誌域必須採用明文進行傳輸。爲確保完整性，明文域可以在SecureData域中重複。

當使用加密時，建議但不是必須，所有的消息體都進行加密。如果一個消息中的重複組數據中的部分數據要加密，這個重複組必須全部進行加密。

預先協商好的加密算法在Logon消息中進行聲明。

4 SESSION PROTOCOL會話協議

一個FIX會話定義爲一個在連接雙方間的的帶有連續序列號的有序消息雙向傳輸流。 單個FIX會話能夠跨越多個連續（不是並行的）的物理連接。在一個維持的，單獨的FIX會話中，參與方能夠多次連接和斷開連接。連接的參與方必須根據單個系統及時間區域需求，公共協商會話的開始和結束。無論什麼原因，重新設置接收和發送序列號爲1，意味着一個新的FIX會話的開始。

建議一個新的FIX會話在每24小時期間建立一次。可以維持24小時的連接和通過設置在Logon消息中的ResetSeqNumFlag建立一套新的序列號。

FIX會話協議基於一個優化模型。普通的數據傳送（無單個消息確認）被假設爲通過消息序列間隙進行錯誤識別。這個部分詳細介紹了FIX會話層和消息序列間隙的實現。

以下術語將在這部分使用：

Valid FIX Message 有效FIX消息 是按照協議正確生成，包含有效消息體長度和效驗域的消息。

Initiator 發起者 建立通信連路，通過發送初始Logon消息發起會話的參與方。

Acceptor 接收方 FIX會話的接收方。負責執行第一層次的認證和通過傳輸Logon消息的確認正式聲明連接請求被接受。

FIX Connection FIX連接 由3部分組成：logon登錄，message exchange消息傳輸，和logout註銷。

FIX Session FIX 會話 由一個或多個FIX Connection FIX連接組成。意思是一個FIX會話可以有多次登錄。4.1

4.1 Logon 登錄

建立一個FIX連接，分別包含3個操作：創建通信層鏈路，接收者認證/接受發起者和消息同步（初始化）。連接流程如下：

l        會話發起者同會話接收者建立通信鏈路。

l        發起者發送一個Logon消息。接收者檢查Logon消息，認證發起者身份。Logon消息包含支持之前雙方協商好的認證方法所必須的數據。如果發起者被成功認證，接收者用一個Logon消息進行響應。如果認證失敗，會話接收者將關閉鏈接，之前可以選擇發送一個Logout消息以提示認證失敗的原因。這個Logout消息不時必須發送的，如果這樣做將會佔用該會話的一個序列號，在某些情況下會有問題，如：在會話期進行多次Logon時。發起者可以在Logon消息後緊接着開始發送消息。然而，接收者可能沒有準備好接收它們。發起者必須等待接收者發送的Logon確認消息才能認爲完全建立回話。

在發起者認證通過之後，接收者立即響應一個Logon確認消息。依據會話使用的加密方法，這個Logon消息可以，也可以不報還同樣的會話密鑰。發起者方將把接收方反悔的Logon確認消息視爲一個FIX會話建立的標誌。如果會話接收方選擇幹邊會話加密密鑰，會話的發起方必須發送一個Logon消息到對方以確認密鑰改變請求。這樣，能讓會話接收者知道發起者何時開始使用新的會話密鑰。雙方有責任診斷和避免在此階段出現無限循環。

l        認證完成之後，發起方和接收方必須在發送任何查詢或新消息之前通過詢問MsgSeqNum域來同步其消息。將Logon消息中的MsgSeqNum同內部監控的下一個希望的序列號進行比較可以指示任何的消息間隙。此外，發起方能通過比較確認Logon消息的MsgSeqNum及下一個期望值來偵測消息的間隙。後面的消息恢復部分文當將介紹如何進行消息間隙的處理。

l        推薦引擎應當在一個臨時的隊列中存儲發送消息系列，在消息間隙關閉時處理它們。這樣可以阻止對n->m，n->m+1，n->m+2，…的重發請求，這些請求能導致許多PossDupFlag=’Y’的消息。

l        當使用ResetSeqNumFlag來維持24小時連接和建立一套新的序列號時，應該按照下面的方式進行處理。雙方應當協商一個復位時間以及此過程的發起方。注意，ResetSeqNum過程的發起方可以與Logon過程的發起方不是同一個。一方通過發送一個TestRequest初始化此過程，並等待一個Heartbeat的響應以確認沒有序列號間隙。一旦收到Hearbeat，發起者應當發送一個帶有ResetSeqNumFlag值爲‘Y’和MsgSeqNum爲1的Logon消息。接收方應當發送一個帶有ResetSeqNumFlag值爲‘Y’和MsgSeqNum爲1的Logon消息作爲響應。此時，任何一方發送的新的消息可以從MsgSeqNum編號爲2開始計數。應當注意，一旦發起方發送設置了ResetSeqNumFlag的Logon消息，接收者必須遵守這個請求，並且作爲最後一個序列號發送的消息的“yesterday”值不再可用。如果此過程的初始化未被正確執行，鏈接應當被關閉，手動關閉方式將會被介入。

4.2 Message exchange 消息交換

初始化過程之後，正常德的消息交換將開始。所有有效的消息格式的細節將在“Adminitrative Message ”管理消息和“Application Messages”應用消息部分介紹。

4.3 Logout

正常的消息交換的終止將通過交換Logout消息來完成。換句話說，通信的終止應被看作異常並作爲一個錯誤進行處理。沒有接收到Logout消息的會話終止應當作參與方的註銷。

推薦發送一個TestRequest消息強制請求從對方獲取Heartbeat。這樣可以幫助判斷沒有序列間隙。

在實際的會話關閉前，Logout的發起者應等待對方響應一個Logout確認消息。這種方式給接收者在需要時一個執行任何間隙填充錯作的機會。一旦ResendRequest消息被接收，接收者應發起Logout操作。會話可以終止，如果接收者在適當的時間表內沒有響應。

注意：註銷不會影響任何指令的狀態。左右活動的指令將繼續有機會在註銷後被執行。

4.4 Message Recovery 消息恢復

在FIX會話初始化過程及會話過程中，通過跟蹤接收序列號，消息間隙的出現將會被偵測到。以下部分介紹瞭如何恢復消息。

如前所述，每個FIX參與方必須爲FIX會話維護兩個序列號，一個是接收序列號，一個是發送序列號，兩者都在建立FIX會話開始時初始化爲1。每個消息被賦予一個唯一的序列號值，並在消息發送後遞增。此外，每個收到的消息都有一個唯一的序列號，接收序列號計數器在收到每個消息後將會被遞增。

當接收序列號與所希望得到的的正確序列號不必配時，必須採取糾錯處理。注意，SeqReset-Reset消息（對比正常德重傳請求處理，僅用於從嚴重災難中進行恢復）對於這個規則來說是個例外，它應當被處理，而不用考慮其MsgSeqNum值。如果接收消息的序列號小於期望接收的序列號，並且PossDupFlag值未被設置，這表示出現一個嚴重錯誤。強烈推薦終止會話，啓用手動干預。如果接收消息的序列號大於期望值，這表明有丟失消息，並通過Resend Request 重傳請求這些消息的重新傳輸。

注意：後續的請求者（requester）指爲請求發送方；重傳者（resender）指請求的響應方。消息重傳和消息同步叫做“間隙填充”（gap filling）。

再收到重傳請求的情況下，重傳者可以用三種方式之一進行響應：

1、按照原先序列號，順序重新傳輸請求消息，並將PossDupFlag設置成‘Y’（除管理消息不被重傳，並需要一個SeqReset-GapFill外）。

2、發出一個SeqReset-GapFill和一個PossDupFlag值爲‘Y’的消息代替管理和應用消息的重傳。

3、發出一個SeqReset-GapFill和一個PossDupFlag值爲‘Y’的消息強制進行序列號的同步。

通常情況下使用1，2的組合。而3則僅用於從災難中，且不能通過間隙填充模式進行數據恢復的場景。

在間隙填充過程中，一些管理消息應不被重傳。取而代之的是一個特殊的SeqReset-GapFill消息將被產生。不能被重傳的消息有：Logon，Logout，ResendRequest，Heartbeat，TestRequest和SeqReset-Reset，SeqRest-GapFill。

所有的FIX協議的實現，都必須監控接收消息以偵測管理消息的重傳（PossDupFlag值標示衝傳）。當接收到這些消息時，應當僅對序列號完整性進行處理，而商業/應用消息應被跳過（如，不處理基於ResendRequest請求的重傳間隙填充）。

如果有連續的管理消息需要重發，推薦只發送一個SeqRest-GagFill消息。SeqRest-GapFill消息的序列號爲下一個希望發送的序列號。GapFill消息的NewSeqNo域包含了這些管理消息中的最高序列號值加上1。如，在一個重傳錯作中，有7個順序的管理消息等待重發。它們的序列號從9到15。替代7個間隙填充消息，一個SeqReset-GapFill消息將會被髮送。此間隙填充消息的序列號被設置爲9，因爲遠端把序列號9作爲下一個期望接收的消息。GapFill消息的NewSeqNo的值爲16，表示下一個發送消息的序列號。

序列號檢查是FIX會話管理最重要的部分。然而，一些FIX消息的序列號處理存在一些不同，下表列出了接收序列號比期望接收序列號大時的處理方法。

注意：除了Reset消息外的所有情況，如果接收序列號小於期望接收序列號，且PossDupFlag未被設置，FIX會話應被終止。在關閉會話前，一個Logout消息和一些描述性文本應被髮送給對端。

 

消息類型	序列號不必陪時的處理
Logon	必須是傳送的第一個消息。認證和接受連接。如果一個消息間隙在logon序列號中被檢測到，那麼在返回一個Logon確認消息後，發送一個ResendRequest
Logout	如果一個消息間隙被檢測到，在確認Logout消息發送之後再發起一個ResendRequest以補償所有丟失消息。不要終止會話。Logout消息的發起方負責終止會話。這樣可以允許Logout發起者對任何ResendRequest消息進行響應。 如果是Logout的發起方，那麼這是一個Logout確認消息，必須在收到之後立即終止會話。 唯一一個“不終止會話”的例外是無效的Logout嘗試。會話接收者有權發送一個Logout消息並立即終止會話。這樣可以減少未經授權的連接嘗試。
ResendRequest	首先執行重傳處理，接着按照自己的順序發送ResendRequest消息用以填充接收消息間隙。
SeqReset-Reset	忽略接收序列號。SeqReset消息的NewSeqNo將包含下一個傳送消息的序列號。
SeqReset-GapFill	發送一個返回ResendRequest。間隙填充消息行爲與SeqReset消息相似。然而，確認沒有消息被連續地跳過是非常重要的。這意味着GapFill消息必須按順序接收。一個無序的GapFill消息時則表明一種異常情況。
所有的其他類型消息	執行間隙填充操作。

4.5 Logon消息的NextExpectedMsgSeqNum處理

NextExpectedMsgSeqNum (789)域從FIX4.4開始加入到Logon消息中，用以支持一個FIX會話的重同步。這個新方法是可選的。其適用必須得到參與方的共同同意。

NextExpectedMsgSeqNum (789)的使用如下：

在Logout的請求階段，會話發起者把期望從會話接收者的下一個MsgSeqNum（34）的值賦於NextExpectedMsgSeqNum (789)。通常，Logon請求發送頭部MsgSeqNum（34）的值表示下一個序列號值。

會話接收者校驗Logout請求，包括NextExpectedMsgSeqNum (789)，確認沒有間隙存在。然後，構建一個Logout響應，其NextExpectedMsgSeqNum (789)值包含了期望從會話發起者接收到的MsgSeqNum（34）值。如果那是一個期望的序列號，MsgSeqNum（34）會被遞加。發送頭部MsgSeqNum（34）按照常規進行構造。

會話發起者等待發送應用消息直到接收到Logon響應。當接收到Logon響應，發起者要校驗該響應和NextExpectedMsgSeqNum (789)以確認沒有消息間隙。

會話雙方採用以下方式對收到的NextExpectedMsgSeqNum (789)進行處理：

1、如果等於下一個期望序列號值，則從該編號開始發送新消息。

2、如果小於下一個期望序列號值，從之前最後傳送的消息到NextExpectedMsgSeqNum (789)按順序恢復所有丟失消息，然後間隙填充將跨過Logon使用的序列號，使用比原Logon大1的序列號繼續發送新的排隊消息。

3、如果大於下一個期望序列號值，發送Logout終止會話。

除了希望自動進行那個間隙填充外，任何一方應給予接收的Logon消息的MsgSeqNum（34）產生一個ResendRequest。如果間隙由Logon消息的MsgSeqNum（34）導致，接收邏輯應希望自動填充間隙以恢復間隙的任何消息序列。

4.6 Standard Message Header標準消息頭

任何管理和應用消息都緊跟在一個標準頭部之後。頭部標示了消息的類型、長度、目標、序列號，來源及創建時間。

兩個域用於協助重發消息。PossDupFlag爲‘Y’表明一個會話級事件導致的消息重傳（如，使用同一個序列號重傳一個消息）。PossResend爲‘Y’表明使用新的序列號重新發出一個消息（如，重新發送一個Order指令）。接收程序應按下述方法進行處理：

PossDupFlag 如果一個消息的序列號表明之前已經收到，忽略該消息；如果沒有，進行正常處理。

PossResend 將消息傳遞給應用程序以判斷是否之前已經收到（如，驗證Order的ID號和參數）。

Message Routing Details – One Firm-to-One Firm (point-to-point)

Message Routing Details – One Firm-to-One Firm（Point-to-point）消息路由-點對點

下表展示了使用SenderCompID，TargetCompID，DeliverToCompID，和OnBehalfOfCompID在兩個企業間的一個單一的FIX會話。假設A爲賣方，B爲買方

	SenderCompID	OnBehalfOfCompID	TartgetCompID	DelivrToCompID
A 到B	A		B
B 到 A	B		A

Message Routing Details-Third Party Message Routing消息路由-第三方消息路由

FIX會話協議具備支持一個FIX會話包含多個參與這者的能力。包括1對多，對對1，或者1對1的形式。此外，一些第三方可以與其它第三方連接，在消息發起者和最終的接收者間形成一個多跳的鏈。SenderCompID，TargetCompID，DeliverToCompID，和OnBehalfOfCompID域用於路由消息。

當一個第三方在另一個企業中間發送一個消息時（使用OnBehalfOfCompID），可以選擇在NoHops重複組中加入它的細節信息。這個重複組構建了消息在第三方重新發送的的一個歷史列表。NoHops重複組不用於協助路由，而是爲接收消息方對參與的第三方進行審計時提供痕跡。當一個第三方轉發一個消息給下一跳（可能是最終接收者，或另一個第三方）時，此第三方可以將其跳信息加到NoHops重複組中（如，將其SenderCompID作爲HopCompID，其SendingTime作爲HopSendingTime，將接收消息的MsgSeqNum或其他引用數據作爲HopRefID ）。

注意：如果OnBeHalfOfCompID或DeliverToCompID消息源識別/路由方法在一個FIX會話中使用，那麼該方法必須在通過此會話傳送的所有消息中使用。

下表提供了在單一FIX會話中表名多個企業參與時SenderCompID，TargetCompID，DeliverToCompID和OnBehalfOfCompID的使用方法。假設A=賣方，B和C表示買方，Q=第三方。

	SenderCompID	OnBehalfOf CompID	TargetCompID	DeliverTo CompID	DeliverTo CompID	HopSendingTime
從A通過Q到B
1 A到Q	A		Q	B
2 Q到B	Q	A	B		Q	A的發送時間
B通過Q響應A
1 B到Q	B		Q	A
2 Q到A	Q	B	A		Q	B的發送時間
A通過Q發送到B和C
1A到Q	A		Q	B
2Q到B	Q	A	B		Q	A的發送時間
3A到Q	A		Q	C
4Q到C	Q	A	C		Q	A的發送時間
B和C通過Q發送到A
1B到Q	B		Q	A
2Q到A	Q	B	A		Q	B的發送時間
3C到Q	C		Q	A
4Q到A	Q	C	A		Q	C的發送時間

 

注意，由於在一個給定的FIX會話中，一些域（如在一個新Order指令中的ClOrdID）必須是唯一的。因此，當使用OnBehalfOfCompI（或DeliverToCompID）進行尋址時，推薦的做法是在OnBehalfOfCompI（或DeliverToCompID）之後加上源地址。這樣，如果A發送消息到Q的ClOrdID爲“123”，那麼Q將“A-123”作爲ClOrdID的值發送到C，以確保唯一性。

 

標準消息頭部如下

Standerd Message Header

Tag （標記）	FieldName （域名）		Req’d （必選）	備註
8	BeginString		Y	FIXT.1.1(不能加密，必須是消息的第一個域)
9	BodyLength		Y	(不能加密，必須是消息的第二個域)
35	MsgType		Y	(不能加密，必須是消息的第三個域)
1128	ApplVerID		N	使用SP標示方法標明應用版本。ApplVerID用於一個特定消息的場景
1129	CstmApplVerID		N	用於支持客戶共同協商認可的功能
49	SenderCompID		Y	（不能被加密）
56	TargetCompID		Y	（不能被加密）
115	OnBehalfOfCompID		N	通過第三方發送消息時交易參與者企業ID（可以內置於堅密數據部分）
128	DeliverToCompID		N	通過第三方發送消息時交易參與者企業ID（可以內置於堅密數據部分）
90	SecureDataLen		N	用於標示消息加密部分的長度時必選（不能加密）
91	SecureData		N	消息體加密時必選。總緊跟在SercureDataLen域之後
34	MsgSeqNum		Y	（可以內置於堅密數據部分）
50	SenderSubID		N	（可以內置於堅密數據部分）
142	SenderLocationID		N	發送者的LocationID（如，地理位置和或席位（desk））（可以內置於堅密數據部分）
57	TargetSubID		N	爲管理消息保留，不針對一個特定用戶。（可以內置於堅密數據部分）
143	TargetLocationID		N	交易參與者LocationID（如，地理位置和或席位（desk））（可以內置於堅密數據部分）
116	OnBehalfOfSubID		N	交易參與者SubID，用於通過第三方傳送消息。（可以內置於堅密數據部分）
144	OnBehalfOfLocation		N	交易參與者的LocationID（如，地理位置和或席位（desk））（可以內置於堅密數據部分）
129	DeliverToSubID		N	交易參與者SubID，用於通過第三方傳送消息。（可以內置於堅密數據部分）
145	DeliverToLocationID		N	交易參與者的LocationID（如，地理位置和或席位（desk））（可以內置於堅密數據部分）
43	PossDupFlag		N	當重傳消息時總是必選，無論是由發送方系統提示，還是作爲重傳請求的響應結果。（可以內置於堅密數據部分）
97	PossResend		N	當消息可能是另一個消息的複製消息且使用一個不同的序列號時必選。（可以內置於堅密數據部分）
52	SendingTime		Y	（可以內置於堅密數據部分）
122	OrigSendingTime		N	當作爲一個ResendRequest的返回結果重傳消息時必選。如果數據不可用，則與SendingTime值相同（可以內置於堅密數據部分）
212	XmlDataLen		N	當標示XmlData消息體長度時必選。（可以內置於堅密數據部分）
213	XmlData		N	包含XML格式的消息塊（如FIXML）。總緊跟在XmlDataLen後。（可以內置於堅密數據部分）
347	MessageEncoding		N	在消息的“Encode”域中使用的消息編碼格式（非ASCII編碼）。使用編碼域時必選。
369	LastMsgSeqNumProcessed		N	FIX引擎到收到、下游應用（如交易系統、指令路由系統）處理過的的最後一個MsgSeqNum值。在每個消息發送時確定。用於參與方偵測消息積壓（未被處理？）。
627	NoHops		N
-〉	628	HopCompID	N
	629	HopSendingTime	N
-〉	630	HopRefID	N

4.7 Standard Message trailer標準消息尾部

每個消息，管理或應用消息，以一個標準尾部結束。該尾部用於分割消息幷包含描述Checksum值的3個數字字符。

Standard Message Trailer

Tag （標記）	FieldName （域名）	Req’d （必選）	備註
93	SignatureLength	N	如果尾部包含簽名則必選。注意，不能包含在SecureData域中。
89	Signature	N	注意，不能包含在SecureData域中。
10	CheckSum	Y	（不能加密，總是消息的最後一個域）

5 ADMINISTRATIVE MESSAGES管理消息

管理消息強調協議的應用需求。以下部分內容描述了每個管理消息，提供消息的圖表。

管理消息由連接各方產生。

5.1 Heartbeat 心跳消息

心跳消息監控通信鏈路的狀態，用於識別一連串消息中最後沒有收到的消息。

當如果一個FIX連接的任何一方在超過HeartBtInt規定的時間間隔後沒有收到任何數據，將發送一個Hearbeat消息。當如果一個FIX連接的任何一方在超過HeartBtInt規定的時間間隔加上一些傳輸時間後沒有收到任何數據，將發送一個Test Request測試請求消息。如果在超過HeartBtInt規定的時間間隔加上一些傳輸時間後仍然沒有收到Heartbeat消息，那麼應視爲連接斷開並應採取糾錯處理。如果HearBtInt設置爲0，則不會產生常規的Heartbeat消息。注意，一個測試請求消息能夠不間隔HeartBtInt的值被髮送，用於強制請求一個Heartbeat消息。

Heartbeat消息作爲測試請求消息的響應，必須包含在請求測試消息中的TestReqID值，用於驗證Heartbeat消息是測試請求消息的響應而不是常規超時的響應。

Heatbeat消息格式如下：

Heartbeat

Tag （標記）	FieldName （域名）	Req’d （必選）	備註
	StandardHeader標準頭部	Y	MsgType=0
112	TestReqID	N	當Heartbeat消息是Test Request消息的響應時必選
	StandartTrailer	Y

5.2 Logon   登陸消息

Logon消息認證一個連接到一個遠程系統的用戶。Logon消息必須是應用程序用於請求初始化一個FIX會話的第一個消息。

HeartBtInt（108）域用於申明產生心跳消息的時間間隔，連接雙方使用形同的HeartBtInt值。其值應被雙方企業一致同意，由Logon消息發起者初始化，並被Logon接收者回應。

當接收到Logon消息，會話接收者將認證參與者的連接請求，併發出一個Logon消息確認連接請求被接受。這個確認Logon消息也能用於發起者驗證連接已經與對端正確建立。

在接收到Logon消息後會話接收者必須立即準備好開始處理消息。會話發起者可以選擇在收到Logon確認消息前傳輸FIX消息，但推薦在收到返回的Logon消息後，完成加密祕要協商後進行正常的消息傳輸。

確認Logon消息可以用於加密祕要協商。如果一個會話密鑰被認爲是弱祕要，一個推薦的新的更加強狀的會話祕要將在Logon消息中返回。這僅在加密協議允許祕要協商時有效。

Logon消息能用於確定支持的消息最大長度MaxMessageSize（能用於控制將大消息進行分節的規則）。也能用於確定雙方接收和發送所支持的消息的類型MsgType。

下表是Logon消息的格式：

Logon

Tag （標記）	FieldName （域名）	Req’d （必選）	備註
	StandardHeader標準頭部	Y	MsgType=A
98	EncryptMethod	Y	不能加密
108	HearBtInt	Y	雙方使用同一個值
95	RawDataLength	N	由一些認證方法使用
96	RawData	N	由一些認證方法使用
141	ResetSeqNumFlag	N	表示FIX會話雙方應復位序列號
789	NextExpectedMsgSeqNum	N	可選，雙方檢測和恢復消息間隙的候選協商方法參照“Logon消息NextExpectedMsgSeqNum ”
383	MaxMessageSize	N	能用於指定所支持接收消息的最大字節數
384	NoMsgTypes	N	指定RefMsgTypes的重複次數
-〉	372 RefMsgType	N	制定一個特定的、被支持的MsgType。如果NoMsgTypes大於0時必選。從Logon消息的發送者角度應當被指定。
-〉	385 MsgDirection	N	表明所支持MsgType的接收或發送方向。當NoMsgTypes大於0時必選。從Logon消息的發送者角度應當被指定。
-〉	1130 RefApplVerID	N	在會話層指定一個消息的應用SP發行版本。SP發行時付值的枚舉域。
-〉	1131 RefCstmApplVerID	N	再會話層指定一個用戶擴展消息的應用。
464	TestMessageIndicator	N	用於指定此FIX會話將發送、接收 “Test” “production”消息。 ？
553	Username	N
554	Password	N	注意，沒有傳輸層加密時存在最小安全性。
1137	DefaultApplVerID	Y	由FIXT承載的FIX的默認版本。
	StandartTrailer	Y

5.3 Test Request 測試請求消息

測試請求消息強制對方發送一個Heartbeat消息。測試請求消息檢查序列號或驗證通信線路狀態。對端應用程序響應一個包含TestReqID的Heartbeat消息。

TestReqID用於檢查對端應用是依據測試請求消息產生的Heartbeat消息，而不是通常的超時。對端應用程序將TestReqID包含在響應Heartbeat消息中。任何字符串可以被用於TestReqID（一個建議是使用時間戳字符串）。

測試請求消息格式如下：

Test Request

Tag （標記）	FieldName （域名）	Req’d （必選）	備註
	StandardHeader標準頭部	Y	MsgType=A
112	TestReqID	Y	不能加密
	StandartTrailer	Y

5.4 Resend Request 重傳請求消息

重傳請求消息由接收用用程序發送用於開始消息的重傳。這個功能在序列號間隙被偵測到時，在接受應用程序丟失消息時，或者作爲一個初始化處理功能時非常實用。

重傳請求消息能用於請求一個單一消息，一定範圍內的消息，或者一個特定消息的所有後續消息。

注意：發送應用程序可能希望考慮重傳消息的消息類型。如：如果在重傳序列中的一個新指令消息在其最初發送後經過一段相當長的時間，那麼發送方可能不希望重傳該消息以提供改變市場條件的潛在可能性。（Seqence Reset-GapFill消息用於發送方不希望發送二跳過這類消息。）

注意：接收程序必須按照順序處理消息。如：如果收到消息8和9，消息7丟失，程序應忽略消息8和9，並要求重傳消息7到9，或者最好重傳消息7到0（0表示序列號無窮大）。後者，作爲當序列號出現混亂，雙方同時嘗試恢復一個間隙時，從當前的某些競爭條件下快速恢復的推薦方法。

1.        爲請求一個單一消息， BeginSeqNo=EndSeqNo

2.        爲請求一定範圍內的消息，BeginSeqNo=請求範圍內第一個消息，EndSeqNo=請求範圍內最後一個消息。

3.        請求特定消息的所有後續消息：BeginSeqNo=請求範圍內第一個消息，EndSeqNo=0。

重傳請求消息格式如下：

Resend Request

Tag （標記）	FieldName （域名）	Req’d （必選）	備註
	StandardHeader標準頭部	Y	MsgType=2
7	BeginSeqNo	Y	不能加密
16	EndSeqNo	Y
	StandartTrailer	Y

5.5 Reject（session-level）駁回消息

當一個接收消息由於違背會話層規則，不能被正確的處理，應發送駁回消息。一個例子是：當一個接收消息通過解密，效驗和檢查，及數據體長度檢查後沒有有效的基礎數據（如，MsgType=&），將產生一個駁回消息。結果是，這些消息將傳遞給交易應用程序，如果需要，將產生商業邏輯級的駁回。

駁回消息應記錄到日誌中，且接收序列號應增加。

注意：接收應用程序應忽略任何干擾消息，不能被解析的及未通過數據完整性檢查的消息。處理下一個FIX消息將導致檢測到一個序列號間隙併產生一個Resend Request消息。FIX引擎應包含處理在此情況下的無限重傳循環。

生成和接收到一個駁回消息表明一個接收或發送程序的邏輯錯誤導致的嚴重的錯誤。

如果發送程序選擇重傳駁回消息，該消息應賦予一個新的序列號值，且PossResend設置爲‘Y’。

無論何時，強烈推薦將描述失敗原因在Text 域中描述（如，INVALID DATA（35））。

如果接收到的一個應用級消息滿足所有會話級規則，該消息應在商業消息級被處理。如果在處理過程中檢測到規則衝突，將產生髮送一個商業績駁回。許多商業級消息都有自己特定的駁回消息。如果沒有，則產生髮送一個Business Message Reject消息。

注意，在收到一個商業消息，滿足會話級規則，但不能被傳送給商業級處理系統時，一個帶有BusinessRjectReason=“Application not available at this time”的Business Message Reject消息將被髮出。

 

會話級駁回消息場景：

SessionRejectReason

0=Invalid tag number    無效的tag編號

1=Required tag missing  tag丟失

2=Tag not defined for this message type 這類消息的Tag沒有被定義

3=Undefined Tag       未知Tag

4=Tag specified without a value 缺少Tag值

5=Value is incorrect (out of range) for this tag tag值錯誤（超界）

6=Incorrect data format for value   錯誤值數據

7=Decryption problem            解密錯誤

8=Signature problem             簽名錯誤

9=CompID problem              企業ID錯

10=SendingTime accuracy problem 發送時間不正確

11=Invalid MsgType             無效的MsgType

12=XML Validation error         XML語法驗證錯誤

13=Tag appears more than once    Tag重複出現

14=Tag specificed out of required order 指定的Tag順序錯誤

15=Repeating group fields out of order 重複組域順序錯誤

16=Incorrect NumInGroup count for repeating group 重複組NumInGroup錯誤

17=Non “data” value includes field delimiter(SOH character) 包含了SOH分界符的錯誤數據

99=Other 其它錯誤

注意：其他的會話級規則衝突可能存在，SessionRejectReason值爲99（Other），並在Text域中進行詳細描述。

駁回消息格式：

Reject

Tag （標記）	FieldName （域名）	Req’d （必選）	備註
	StandardHeader標準頭部	Y	MsgType=3
45	RefSeqNum	Y	被駁回消息的MsgSeqNum
371	RefTagID	N	被參照的FIX域tag值
372	RefMsgType	N	被參照的FIX消息MsgType值
373	SessionRejectReason	N	會話級駁回消息錯誤代碼
58	Text	N	解釋駁回原因的文本信息
354	EncodedTextLen	N	如果使用EncodeText域，必選，且EncodeText必須緊跟在該域之後
355	EncodedText	N	使用MessageEncoding 域制定的編碼規則對Text域內容的編碼數據（非ASCII碼）
	StandartTrailer	Y

  

5.6 Sequence Reset（Gap Fill）序列號復位（間隙填充）消息

序列號復位消息有兩種模式：Gap Fill模式和Reset模式。

5.6.1Gap Fill 模式

在下列情況下，Gap Fill模式用於響應當出現一個或多個消息必須被跳過時的Resend Request消息

1.        在常規的重傳處理過程中，發送應用程序可以選擇不發送消息（如，一個過期的指令）。

2.        在常規的重傳處理過程中，大量的管理消息將跳過而不重傳（如：Heartbeat， TestRequest 消息）。

GapFillFlag（123）域爲‘Y’時，爲Gap Fill模式。

如果GapFillFlag（123）域設置爲‘Y’，MsgSeqNum應同標準消息序列號規則保持一致（如，序列號Reset GapFill模式消息的MsgSeqNum應爲GapFIll消息的最開始的MsgSeqNum,因爲其值爲遠端程序希望接收的消息序列號）。

5.6.2Reset Mode 復位模式

復位模式包括了指定一個任意的、數值更大的、接收者期望的Reset-Reset消息序列號，並用於在出現不可恢復的應用程序錯誤時重新建立一個FIX會話。

復位模式由GapFillFlag爲‘N’時，或被忽略時被指定。

如果GapFillFlag沒有出現，或其值爲‘N’，可以認爲Sequence Reset消息的目標是從序列號混亂時的恢復。在序列號的Reset-Reset模式中，在消息頭中的MsgSeqNum將被忽略（如，當接受到帶有錯誤的MsgSeqNum序列號的Sequence Reset-Reset模式消息時，不產生重傳請求）。序列號復位的Reset消息不應被當作揖個重傳請求的常規響應（使用序列號復位的Gap Fill模式）。序列號復位的Reset模式僅在當使用序列號復位的Gap Fill模式無法恢復時進行災難恢復。注意，使用序列號復位模式時有可能造成消息丟失。

5.6.3Rules for processing all Sequence Reset messages處理所有序列號復位消息的規則

發送程序將啓動序列號復位。所有情況下，這個消息指定NewSeqNo以作爲消息接收方期望接收的下一個消息的序列號的復位，緊接在消息和/或被挑過的序列號 ？

序列號復位，近能增加序列號。如果一個序列號復位消息嘗試減小期望接收消息的序列號時，應被當作揖個嚴重錯誤而被拒絕。多個Resend Request重傳請求可能在接連着被髮起（如，5道10，接着5到11）。如果序列號8，10，11是應用消息而5到7和9是管理消息，那麼重傳請求的結果爲：序列號復位GapFill模式下的NewSeqNo爲8，消息8；序列號復位GapFill模式下的NewSeqNo爲10，消息10。也可以是序列號復位GapFill模式下的NewSeqNo爲8，消息8；序列號復位GapFill模式下的NewSeqNo爲10，消息10，和消息11。必須小心地忽略嘗試減少期望序列號值的複製的序列號復位GapFill模式消息。可以通過檢查MsgSeqNum是否小於期望值來檢查。如果是，那麼該序列號復位GapFill模式消息爲複製消息，應被忽略。

序列號復位消息格式：

Sequence Reset

Tag （標記）	FieldName （域名）	Req’d （必選）	備註
	StandardHeader標準頭部	Y	MsgType=4
123	GapFillFlag	N
36	NewSeqNo	Y
	StandartTrailer	Y

5.7 Logout註銷消息

Logout消息發起或確認一個FIX會話的終止。沒有Logout消息交換的連接斷開應被視爲一個異常情況。

在實際的關閉會話前，Logout發起者應等待對端的Logout確認消息的響應。這樣可以給遠端在必要時執行一些Gap Fill操作的機會。如果遠端在規定的時間間隔後沒有響應，會話可以終止。

在發送Logout消息後，註銷發起者不應發送任何消息，除非註銷的接收者通過ResendRequest消息請求發送消息。

註銷消息格式如下：

Logout

Tag （標記）	FieldName （域名）	Req’d （必選）	備註
	StandardHeader標準頭部	Y	MsgType=5
58	Text	N
354	EncodedTextLen	N	如果使用EncodeText域，必選，且EncodeText必須緊跟在該域之後
355	EncodedText	N	使用MessageEncoding 域制定的編碼規則對Text域內容的編碼數據（非ASCII碼）
	StandartTrailer	Y

5.8 CheckSum Calculation 校驗和計算

一個FIX消息校驗和通過計算到ChechSum域（但不包括）的消息的每個字節和得到。然後，校驗和被轉換爲模256的數字用於傳送和比較。校驗和在所有加密操作之後被計算。

爲了便於傳輸，校驗和必須以可打印字符形式進行傳輸，因此，校驗和被轉換位3個ASCII數字。

比如：如果消息的校驗和爲274，則模256後爲18（256+18 = 274）。這個值將採用|10=018|進行傳輸，其中“10=”是校驗和域的標籤。

產生校驗和的代碼示列如下：

char *GenerateCheckSum( char *buf, long bufLen )

{

static char tmpBuf[ 4 ];

long idx;

unsigned int cks;

for( idx = 0L, cks = 0; idx < bufLen; cks += (unsigned int)buf[ idx++ ] );

sprintf( tmpBuf, “%03d”, (unsigned int)( cks % 256 ) );

return( tmpBuf );

}

6 FIX 會話層測試用例和期望行爲

6.1 Applicability 適用性

本文檔在2002年9月20日最後被修訂，當時的FIX協議的最新版本爲帶有20020930的擴展的FIX 4.3 。此文當適用於FIX4.X，除非特別說明。

6.2When to send a Logout vs. when to just disconnect何時發送Logout與僅斷開連接

一般情況下，一個Logout消息應在關閉一個連接前發送。如果這個Logout消息是源於一個錯誤條件，Logout的Text域應提供錯誤原因的描述，爲遠端FIX系統提供問題診斷的操作支持。這裏有2個例外，推薦不發送Logout消息：

1、在登陸階段，如果會話發起者的SenderCompID，TargetCompID或IP其中一個無效時，推薦立即終止會話，不發送Logout消息。這個登陸嘗試有可能使一個未經授權的破壞系統的未認證嘗試，因此，企業不希望泄露其FIX系統的任何信息，如，哪個SenderCompID，TargetCompID是有效的，或所支持的FIX版本。

2、在登陸階段，當一個有效的FIX會話已經被一個企業使用時，該企業的第2次連接嘗試的Logon消息被接受時，推薦會話接收者立即中斷該第2次連接嘗試，不發送Logout消息。發送一個Logout消息將冒着妨礙和影響當前FIX連接的風險。例如：在一些FIX實現系統中，發送一個Logout消息可能會消耗一個序列號，這樣將會導致在一個已經建立的FIX會話中的序列號混亂。

在其他情況下，如果發送一個Logout消息不產生風險和安全衝突，Logout消息應隨同描述信息一起發送。

6.3 When to send a Session Reject vs. when to ignore the message 何時發送會話駁回與何時忽略消息

以下內容從FIX協議規範中的Reject消息定義中摘抄：

注意：接收程序應忽略任何文本混亂，不能被解析以及數據完整性檢查失敗的消息。處理下一個右下的FIX消息將導致檢測到一個序列號間隙併產生一個重傳請求消息Resend Request。這種情況下，FIX引擎應包含識別重傳無限循環的邏輯。

FIX協議採取樂觀的觀點。它假設一個混亂的消息是由於傳輸中出現的錯誤，而不是FIX系統的問題。因此，如果發送一個重傳請求消息（Resend Request），該混亂消息將被正確得重傳。如果一個消息沒被認爲是混亂的，那麼，推薦發送一個會話級駁回消息。

6.4 What constitutes a garbled message 什麼樣的情況認爲是一個混亂消息

1.        BeginString（tag#8）不是一個消息中的第一個tag或不是8=FIXT.n.m.的格式。

2.        BogyLength（tag#9）不是一個消息中的第二個tag或沒有包含正確的字節數。

3.        MsgType（tag#35）不是一個消息中的第三個tag。

4.        Checksum（tag#10）不適最後一個tag或沒有包含正確的值。

如果丟失MsgSeqNum（tag#34），一個Logout消息將被髮送以終止FIX連接。因爲這種情況意味着一個嚴重的應用程序錯誤。

6.5 FIX Session-level State Matrix FIX會話層狀態舉證

Precedence 次序	State 狀體	Initiator 發起者	Acceptor 接收者	Descriptioin 描述
1	斷開 當天未連接	Y	Y	當前處於斷開狀態，當日未進行連接嘗試。沒有MsgSeqNum被使用（下一個當日的連接的MsgSeqNum值爲1）。
2	斷開 當日開始連接	Y	Y	當前處於斷開狀態，嘗試建立當日連接，這樣，MsgSeqNum開始被消耗（下一個當日連接時，MsgSeqNum將從其（last+1）開始）
3	檢測到網絡連接的中斷	Y	Y	處於連接狀態時，檢測到一個網絡連接中斷（如TCP socket關閉）。斷開網絡連接並關閉該會話的配置。
4	等待連接	N	Y	會話登陸消息接收者等待對端的連接。
5	初始話（發起）連接	Y	N	會話登陸消息發起者同對端建立連接。
6	網絡連接建立	Y	Y	雙方建立網絡連接。
7	發送Logon發起消息	Y	N	會話登陸發起者發送Logon 消息。 ***異常：24小時會話
8	收到Logon發起消息	N	Y	會話登陸接收者收到對端的Logon消息 ***異常：24小時會話
9	Logon發起消息響應	N	Y	會話登陸接收者使用Logon消息與對端握手，響應對端Logon消息。
10	處理ResendRequest	Y	Y	接收和響應對端發送的對消息的ResendRequeset消息，和（或）對MsgSeqNum所請求範圍的SequenceReset-Gap Fill消息。修改以駁回接收到的MsgSeqNum小於LastSeqNum的Resend Request消息。
11	收到MsgSeqNum過大	Y	Y	從對端接收到過大的MsgSeqNum，將消息排隊暫存，發送ResendRequest消息
12	等待/處理ResendRequest響應	Y	Y	處理請求的MsgSeqNum請求的、PossDupFlag=’Y’的消息，和/或從對端進行的SequenceRset-Gap Fill消息。將MsgSeqNu過高的接收消息排隊暫存。
13	在實踐間隔後未收到消息	Y	Y	沒有非混亂消息在HeartBeatInt+響應時間內被接收，發送TestRequest消息。
14	等待/處理TestRequest消息響應	Y	Y	處理接收消息。當接收到非混亂消息後，復位心跳間隔時間。
15	接收Logout消息	Y	Y	從對端接收到發起註銷/連接斷開的Logout消息。如果MsgSeqNum過高，發送RsendRequest。如果發送，等待一定週期，以完成ResendRequest的響應處理。注意，依據Logout的原因，對端可能不能執行該請求。 發送Logout消息作爲響應並等待一定時間讓對端斷開網絡連接。注意，對端可能發送ResendRequest消息，如果Logout響應消息的MsgSeqNum過高並重新發起Logout操作。
16	發起Logout處理	Y	Y	識別優雅斷開連接的條件和原因（如：日終，多個未響應的TestRequest消息發送後，MsgSeqNum過高等）。發送Logout效益給對端。等待一個時間週期以接收Logout響應。在這期間，如有可能，處理新接收的消息和/或ResendRequest。注意，一些註銷/終止條件（如數據庫/消息存儲失敗），可能要求緊接在初始滬Logout消息發送後立即止網絡連接。斷開該會話的網絡連接並關閉該會配置。
17	活動/正常會話	Y	Y	網絡連接建立後，Logon消息成果交換完成，接收和發送的MsgSeqNum都是所期望的順序，並且Heartbeat 或其他消息在（HeartBeatInt +響應週期）內被接收。
18	等待Logon確認	Y	N	會話發起者等待會話接收者發送Logon確認消息。

6.6 FIX Logon Process State Transition Diagram     FIX登陸消息處理狀態轉換圖

Session Initiator（e.g. buyside）Action 會話發起者（如，買方）行爲	Session Acceptor（e.g. sellside）Action會話接收者（如，賣方）行爲	Session Initiator（e.g.buyside）State會話發起者（如，買方）狀態	Session Acceptor（e.g. sellside）State會話接收者（如，賣方）狀態
開始		未連接-當日未連接 未連接-當日連接	等待連接
連接		發起連接 （可能）檢測到網絡連接中斷	等待連接
	接受連接	建立網絡連接	建立網絡連接
發起登陸		發送發起登陸消息Logout	建立網絡連接
	收到發起登陸消息Logout	發送發起登陸消息Logout	收到發起登陸消息Logout
	發送發起登陸消息響應	發送發起登陸消息Logout	發起Logon的響應   （可能）發起 Logout處理   （可能）接收到的MsgSeqNum過高
	（可能）發送ResendRequest		發起Logon響應   （可能）接收到的MsgSeqNum過高
接收發起登陸消息的響應		（可能）活動/正常的會話 （可能）發起 Logout處理（如，MsgSeqNum過高）	發起Logon的響應
（可能）發送RsendRequest		（可能）活動/正常的會話 （可能）接收的MsgSeqNum過高	（可能）活動/正常的會話 （可能）處理ResendRequest
		活動/正常的會話	活動/正常的會話

6.7 FIX Logout Process State Transition Diagram    FIX Logout處理狀態轉換圖

Logout Initiator: Action Logout發起者行爲ie	Logout Acceptor Action Logout接收者行爲	Logout Initiator State Logout發起者狀態	Logout Acceptor State Logout接收者狀態
開始		1.        活動/正常的會話 2.        沒有在時間間隔內收到消息 3.        等待/處理響應TestRequest

 

7 Test cases 測試用例

這些測試用例來自進行測試的FIX系統。FIX系統達到某種狀態，或激發條件，被期望採取由“期望行爲”所定義的正確動作。

7.1 Buyside-oriented(session initiator) Logon and session initiation test case

Ref ID參考號	Pre- Condi- tion 前置 條件	Test case 測試 用例	Mandaory /Optional 強制 /可選	Condition /Stimulus 狀態 /激發	Expected Beheavior期望行爲
1B		連接併發送Logon消息	Mandatory 強制	a 建立網絡連接	同對端成功創建TCP socket連接
				b 發送Logon消息	發送Logon消息
				c 收到有效Logon響應消息	如果MsgSeqNum過高，則發送Resend Request消息
				d 收到無效Logon消息	1.         在測試輸出上產生一個錯誤狀態。 2.         （可選）發送Reject駁回消息，其RefMsgSeqNum 參照Logon消息的MsgSeqNum的值，在Text 域填寫錯誤狀態。 3.         發送Logout消息，在其Text域填寫錯誤狀態。 4.         斷開連接。
				e 收到任何非Logon消息	1.         記錄日誌：第一個消息不是Logon。 2.         同上 3.         同上 4.         同上

7.2 Sellside-oriented(session acceptor) Logon and session initiation test case  

Ref ID參考號	Pre- Condi- tion 前置 條件	Test case 測試 用例	Mandaory /Optional 強制 /可選	Condition /Stimulus 狀態 /激發	Expected Beheavior期望行爲
1S		收到Logon消息	Mandatory 強制	a收到有效Logon響應消息	1.         用Logon響應消息進行響應 2.         如果MsgSeqNum過高，則發送Resend Request消息
				b 收到帶有重複特性的Logon消息（如，當存在連接時的同樣的IP，Port，SenderCompID，TargetCompID，等）	1.         產生，並測試輸出一個錯誤狀態。 2.         不發送任何消息，斷開連接。（注意，發送Reject消息，或Logout消息將消耗MsgSeqNum）
				c 收到Logon消息，帶有未認證/未配置特性（如，同系統配置比較，無效SendCompID，無效TargetCompID，無效源IP等）	1.         產生，並測試輸出一個錯誤狀態。 2.         不發送任何消息，斷開連接。（注意，發送Reject消息，或Logout消息將消耗MsgSeqNum）
				d 收到無效Logon消息	1.         在測試輸出上產生一個錯誤狀態。 2.         （可選）發送Reject駁回消息，其RefMsgSeqNum參照Logon消息的MsgSeqNum的值，在Text 域填寫錯誤狀態。 3.         發送Logout消息，在其Text域填寫錯誤狀態。 4.         斷開連接。
		收到任何非Logon消息	Mandatory 強制	第一個消息不時一個Logon消息	1.         記錄日誌：第一個消息不是Logon。 2.         斷開連接

 

7.3 Test cases applicable to all FIX systems

Ref ID參考號	Pre- Condi- tion 前置 條件	Test case 測試 用例	Mandaory /Optional 強制 /可選	Condition /Stimulus 狀態 /激發	Expected Beheavior期望行爲
2		收到消息標準頭	Mandatory 強制	A收到期望的MsgSeqNum	接受該消息的MsgSeqNum
				b 收到比期望值大的MsgSeqNum	用Resend Request消息作爲響應
				c 收到比期望值小的MsgSeqNum且PossDupFlag不爲‘Y’   列外：SeqReset-Reset	1.         推薦FIX引擎嘗試發送一個Logout，並帶有Text的值爲“MsgSeqNum too low，expecting X but receiced Y” 2.         （可選）等待Logout消息的響應（注意：可能會出現的錯誤的MsgSeqNum）或者等待2秒無論什麼先到達 3.         斷開連接 4.         產生、輸出錯誤報告
				d 收到混亂消息	1.         當做混亂消息並忽略消息（不增加輸入MsgSeqNum），繼續接收消息。 2.         產生並輸出“警告”測試信息。 3.         發送Logout消息，在其Text域填寫錯誤狀態。 4.         斷開連接。
				e PossDupFlag值爲‘Y’；OrigSendingTime值小於或等於SendingTime且MsgSeqNum比期望值小。 注意：OrigSendingTime應遭遇SendingTime除非該消息在同一秒內重傳。	1.         檢查是否該MsgSeqNum值消息已經被接收。 2.         如果已經收到，忽略該消息，否則接收並處理該消息。
				f PossDupFlag值爲‘Y’，OrigSendingTime比SendingTime大，且MsgSeqNum等於期望值 注意：OrigSendingTime應遭遇SendingTime除非該消息在同一秒內重傳。	1.         發送Reject駁回消息，參照不準確的發送時間（>=FIX4.2：SessionRejectReason = “SendingTime 準確性問題”） 2.         增加接收MsgSeqNum值 3.         可選： a)         發送Logtout消息，參照不準確的SendingTime值 b)        （可選）等待Logout響應（注意有可能有不準確的SendingTime）或者等待2秒無論什麼消息先到達。 c)        斷開連接。 產生、輸出一個“錯誤”測試信息。
				g PossDupFlag值爲‘Y’，OrigSendingTime沒有指定 注意：在響應Resen Request消息時，始終將OrigSendingTime設置爲消息最開始發送的時間，不是當前SendingTime時間，並且PossDuFlag=‘Y’	1.         發送Reject駁回消息，參照不準確的發送時間（>=FIX4.2：SessionRejectReason = “tag丟失”） 2.         增加接收MsgSeqNum值
				h 收到在測試Profile中指定的期望的BeginString值，並且匹配發送消息的BeginString值	接受該消息的BeginString
				i收到不是在測試Profile中指定的期望的BeginString值，並且匹配發送消息的BeginString值	1.         發送Logout消息參照錯誤的BeginString值。 2.         （可選）等待Logout響應消息（注意可能有錯誤的BeginString）或者等待2秒無論什麼先到達 3.         斷開連接。 4.         產生、輸出“錯誤“測試信息。
				j收到在測試Profile中指定的期望的SenderCompID和TargetCompID值	接受該消息的SenderCompID和TargetCompID
				k收到不是在測試Profile中指定的期望的SenderCompID和TargetCompID值	1.         發送Reject駁回消息，參照無效的SenderCompID和TargetCompID。（>=FIX4.2：SessionRejectReason = “CompID錯誤”） 2.         增加接收MsgSeqNum值。 3.         參照錯誤的SenderCompID或TargetCompID值發送Logout消息。 4.         （可選）等待Logout響應消息（注意可能有錯誤的SenderCompID或TargetCompID值）或者等待2秒無論什麼先到達 5.         斷開連接 6.         產生、輸出“錯誤”測試信息。
				l 收到正確的BodyLength值	接受該消息的BodyLength
				m收到正確的BodyLength值	1.         當做混亂消息並忽略（不增加接收MsgSeqNum值），繼續接收消息。 2.         產生、輸出“警告”測試信息。
				N SendingTime值使用UTC格式並在一個基於原子時間的合理範圍內（如，2秒）	接受該消息的SendingTime
				O收到的SendingTime值即不使用UTC格式也不是在一個基於原子時間的合理範圍內（如，2秒）	1.         發送Reject駁回消息，參照無效的SendingTim。（>=FIX4.2：SessionRejectReason = “SendingTime精確性問題”） 2.         增加接收MsgSeqNum值 3.         參照不精確的SendingTime發送Logout消息。 4.         （可選）等待Logout響應消息（注意可能有不精確的SendingTime）或者等待2秒無論什麼先到達 5.         斷開連接 6.         產生、輸出“錯誤”測試消息。
				P 收到有效MsgType值（在規範中定義或用戶自定義文檔中定義）	接受該消息的MsgType
				收到無效MsgType值（沒有在規範中定義或用戶自定義文檔中定義）	1.         發送Reject駁回消息，參照無效的MsgType。（>=FIX4.2：SessionRejectReason = “無效的MsgType”） 2.         增加接收MsgSeqNum值 3.         產生、輸出“警告”測試消息
				R收到有效MsgType值（在規範中定義或用戶自定義文檔中定義）但不被測試Profile支持，或沒再其中註冊。	1.         if < FIX 4.2 參照有效的但不被支持的MsgType發送Reject駁回消息。 2.         if >=FIX4.2 a)         發送Business Message Reject駁回消息，參照有效但不被支持的MsgType。（>=FIX4.2：BusinessRejectReason = “不支持的MsgType” 3.         增加接收MsgSeqNum值 4.         產生、輸出“警告”測試消息
				S 收到的BeginStirng，BodyLength，和MsgType是消息的前三個域	接受該消息
				t 收到的BeginStirng，BodyLength，和MsgType是消息的前三個域	1.         當做混亂消息並忽略（不增加接收MsgSeqNum值），繼續接收消息。 2.         產生、輸出“警告”測試消息
3		接收標準消息尾	強制	a 有效CheckSum	1.         接受消息
				B 無效CheckSum	1.         當做混亂消息並忽略（不增加接收MsgSeqNum值），繼續接收消息。 2.         產生、輸出“警告”測試消息
				C 混亂消息	1.         當做混亂消息並忽略（不增加接收MsgSeqNum值），繼續接收消息。 2.         產生、輸出“警告”測試消息
				D CheckSum爲消息的最後一個域，長度爲3，並由分界符<SOH>分隔	接受該消息
				E CheckSum不是消息的最後一個域，長度不爲3，或不是由分界符<SOH>分隔	1.         當做混亂消息並忽略（不增加接收MsgSeqNum值），繼續接收消息。 2.         產生、輸出“警告”測試消息
4		發送Heartbeat消息	強制	A 當前心跳時間間隔內無數據發送（HeartBearInt域）	發送Heartbeat消息
				B接收到一個Test Request消息	發送Heartbeat消息，附帶Test Request消息的TestReqID
5		接收Heartbeat消息	強制	有效的Heartbeat消息	接受Heartbeat消息。
6		發送Test Request	強制	當前心跳時間間隔+某個時間週期（20%的HeartBeatInt值）內無數據接收	1.         發送Test Request消息 2.         跟蹤確認一個使用TestReqID的Heartbeat被接收（可以不是下一個消息）。
7		接收Reject駁回消息	強制	有效的Reject消息	1.         增加接收MsgSeqNum值 2.         繼續接收消息
8		接收Resend Request消息	強制	有效的Resend Request消息	使用應用層消息，和按照“消息恢復”規則在請求範圍內使用SequenceReset-Gap Fill消息進行響應
9		同步序列號	可選	應用程序故障	發送Sequence Reset-Reset消息或手動復位
10		接收Sequence Reset（Gap Fill）	強制	A 收到Sequence Reset（Gap Fill）消息，NewSeqNo > MsgSeqNum 且MsgSeqNum > 期望序列號	發送Resend Request，在最後一個期望MsgSeqNum到接收到的MsgSeqNum範圍內填衝消息間隙。
				B收到Sequence Reset（Gap Fill）消息，NewSeqNo > MsgSeqNum 且MsgSeqNum = 期望序列號	設置下一個期望序列號爲NewSeqNo
				C收到Sequence Reset（Gap Fill）消息，NewSeqNo > MsgSeqNum 且MsgSeqNum < 期望序列號且 PossDupFlag = “Y”	忽略消息
				D收到Sequence Reset（Gap Fill）消息，NewSeqNo > MsgSeqNum 且MsgSeqNum < 期望序列號且 沒有PossDupFlag = “Y”	1.         如果可能，在斷開FIX會話前，發送帶有Text域爲“MsgSeqNum too low, expecting X received Y,”的Logout消息 2.         （可選）等待Logout響應（注意可能有不精確的MsgSeqNum）或者等待2秒無論什麼先到達） 3.         斷開連接 4.         產生、輸出“錯誤”測試信息。
				E收到Sequence Reset（Gap Fill）消息，NewSeqNo <= MsgSeqNum 且MsgSeqNum = 期望序列號	發送Reject（會話層）駁回消息，攜帶信息“attempt to lower sequnce number, invalid value NewSeqNum=<x>”
11		接收Sequence Reset（Reset）	強制	A 收到Sequence Reset（Gap Fill）消息，NewSeqNo> 期望序列號	1.         接受該Sequence Reset消息，忽略其MsgSeqNum 2.         將期期望序列號設置爲NewSeqNo
				B收到Sequence Reset（Gap Fill）消息，NewSeqNo= 期望序列號	1.         接受該Sequence Reset消息，忽略其MsgSeqNum 2.         產生、輸出“警告”測試信息。
				C收到Sequence Reset（Gap Fill）消息，NewSeqNo< 期望序列號	1.         接受該Sequence Reset消息，忽略其MsgSeqNum 2.         發送Reject會話層駁回消息，參照無效的MsgType。（>=FIX4.2：SessionRejectReason = “此tag值錯誤（超界）”） 3.         不增加接收MsgSeqNum值 4.         產生、輸出“錯誤”測試消息。 5.         不能減小序列號。
12		發起註銷過程	強制	發起Logout	1.         發送Logout消息 2.         10秒內等待Logtout響應（注意，可能由於出現的通信問題不能收到）。如果沒有收到，產生輸出“警告”測試消息 3.         斷開連接。
13		接收Logtout消息	強制	A 收到有效的Logout消息作爲請求註銷處理過程的響應	斷開連接，不發送消息。
				B 接收到有效的非請求的Logout消息	1.         發送Logout響應消息。 2.         10秒內等待對端斷開連接。如果超過等待時間，斷開連接，產生輸出“錯誤”測試消息
14		接收應用消息或管理消息	強制	A收到的域識別符（tag值）未在規範文檔中定義 例外：未在規範文檔中定義，但在測試Profile中作爲用戶定義的tag	1.         發送Reject會話層駁回消息，參照無效的tag。（>=FIX4.2：SessionRejectReason = “無效的tag”） 2.         增加接收MsgSeqNum。 3.         產生、輸出“錯誤”測試消息
				B 接收消息中必選Tag丟失	1.         發送Reject會話層駁回消息，參照丟失的必選tag。（>=FIX4.2：SessionRejectReason = “必選tag丟失”） 2.         增加接收MsgSeqNum。 3.         產生、輸出“錯誤”測試消息
				C 接收消息tag在規範文檔中定義，但不是爲該消息類型定義的	1.         發送Reject會話層駁回消息，參照丟不是爲該消息類型定義的tag。（>=FIX4.2：SessionRejectReason = “該消息未定義此Tag”） 2.         增加接收MsgSeqNum。 3.         產生、輸出“錯誤”測試消息
				D 接收消息tag在規範文檔中定義，但爲空值（如55=<SOH>）	1.         發送Reject會話層駁回消息，參照已定義但值爲空的tag。（>=FIX4.2：SessionRejectReason = “指定的Tag值爲空”） 2.         增加接收MsgSeqNum。 3.         產生、輸出“錯誤”測試消息
				E 接受消息特定tag值取值、取值範圍錯誤，或不是有效的枚舉值。 例外：在測試Profile中作爲用戶自定義的未在規範文檔中定義的枚舉值	1.         發送Reject會話層駁回消息，參照取值錯誤的tag。（>=FIX4.2：SessionRejectReason = “Tag值錯誤（超界）”） 2.         增加接收MsgSeqNum。 3.         產生、輸出“錯誤”測試消息
				F接受消息特定tag值格式（語法）錯誤	1.         發送Reject會話層駁回消息，參照取值格式錯誤的tag。（>=FIX4.2：SessionRejectReason = “值格式錯誤”） 2.         增加接收MsgSeqNum。 3.         產生、輸出“錯誤”測試消息
				G 消息結構不是和ader+body+trailer	1.         發送Reject會話層駁回消息，參照不正確地消息結構。（>=FIX4.2：SessionRejectReason = “指定的Tag順序錯誤”） 2.         增加接收MsgSeqNum。 3.         產生、輸出“錯誤”測試消息
				H 消息中一個tag不是重複組的組成部分，但被多次指定	1.         發送Reject會話層駁回消息，參照重複的tag。（>=FIX4.2：SessionRejectReason = “Tag重複出現”） 2.         增加接收MsgSeqNum。 3.         產生、輸出“錯誤”測試消息
				I 消息中重複組count域值錯誤	1.         發送Reject會話層駁回消息，參照錯誤的count域。（>=FIX4.2：SessionRejectReason = “重複組無效的NumInGroup計數”） 2.         增加接收MsgSeqNum。 3.         產生、輸出“錯誤”測試消息
				J 重複組域順序未匹配規範	1.         發送Reject會話層駁回消息，參照重複組錯誤的域順序。（>=FIX4.2：SessionRejectReason = “重複組域順序錯誤”） 2.         增加接收MsgSeqNum。 3.         產生、輸出“錯誤”測試消息
				K 域的tag標識中含有多個<SOH>(非域數據)	1.         發送Reject會話層駁回消息，參照域的含有多個<SOH>的tag標識。（>=FIX4.2：SessionRejectReason = “非域數據包含分界符號(SOH 字符)”） 2.         增加接收MsgSeqNum。 3.         產生、輸出“錯誤”測試消息
				L 當應用曾處理或系統無效收到消息	1.         if <FIX 4.2 a)         發送Reject會話層駁回消息，參考應用處理無效。 2.         if >=FIX 4.2 a)         發送Business Message Reject消息，參考域參考應用處理無效。（>=FIX4.2：BusinessRejectReason = “應用程序無效”） 4.         增加接收MsgSeqNum。 5.         產生、輸出“警告”測試消息
				M 消息中常規必選域丟失	1.         if <FIX 4.2 b)        發送Reject會話層駁回消息，參考丟失的常規必選域。 2.         if >=FIX 4.2 a)         發送Business Message Reject消息，參考丟失的常規必選域。（>=FIX4.2：BusinessRejectReason = “常規必選域丟失”） 3.         增加接收MsgSeqNum。 4.         產生、輸出“錯誤”測試消息
				N 在明文中出現的Tag數與密文中出現的相同，但Tag值不同	1.         發送Reject會話層駁回消息，參照明文和密文中具有相tag數，但值不同的域。（>=FIX4.2：SessionRejectReason = “解密問題/錯誤”） 2.         增加接收MsgSeqNum。 3.         產生、輸出“錯誤”測試消息
15		發送應用或管理消息以測試正常和異常的行爲/響應		發送多個消息同類消息，其頭部和數據體域順序不同，以驗證消息接受（排除有順序限制的）	消息被接受並且其後續消息的MsgSeqNum被接受。
16		排隊待發送消息	強制	A 當處於連接斷開時待發消息排隊	排隊待發送消息。注意，有2種方法： 1.         排隊消息，不考慮MsgSeqNum a)         存儲消息數據。 2.         使用下一個MsgSeqNum值，排隊每一個消息 a)         採用消耗下一個MsgSeqNum值的方式，存儲消息數據。 注意：SendingTime（Tag#52）：必須包是消息發送的時間，而不是消息進入排隊的時間。
				B 帶有排隊消息的重連。	1.         完成登陸過程（連接，交換Logon消息） 2.         如可能，完成MsgSeqNum恢復過程。 3.         推薦短暫延遲或使用TestRequest/Heartbeat確認MsgSeqNum恢復完成。 4.         注意，這裏有2種有效的排隊方法： a)         排隊消息，不考慮MsgSeqNum                          i.              使用新MsgSeqNum發送排隊消息（大於Logon消息的MsgSeqNum）。 b)        使用下一個MsgSeqNum值，排隊每一個消息                          i.              （注意，）Logon消息的MsgSeqNum大於排隊消息的MsgSeqNum。                        ii.              對端將發起ResendRequest請求這個範圍內丟失的消息                       iii.              重發每個排隊消息，將PossDupFlag設置爲‘Y’ 注意：SendingTime（Tag#52）：必須包是消息發送的時間，而不是消息進入排隊的時間。
17		加密支持	可選	A 接收Logon消息，帶有有效的北支持的EncryptMethod	1.         接受該消息 2.         執行適當的解密或加密方法。 3.         使用同一個EncryptMethod方法響應Logon消息。
				B 收到Logon消息，帶有無效的或不支持的EncryptMethod	1.         發送Reject會話層駁回消息，參照無效的或不支持EncryptMethod。（>=FIX4.2：SessionRejectReason = “解密問題”） 2.         增加接收MsgSeqNum值。 3.         發送Logout消息，參照無效的或不支持EncryptMethod 4.         （可選）等待Logout響應（注意可能有解密問題）或者等待2秒無論什麼先到達） 5.         斷開連接 6.         產生、輸出“錯誤”測試消息。
				C 收到消息，帶有SignatureLength和Signature值	接受該消息
				D 收到消息，帶有無效的SigntureLength值	1.         發送Reject會話層駁回消息，參照無效的SignatureLength值。（>=FIX4.2：SessionRejectReason = “簽名問題”） 2.         增加接收MsgSeqNum值。 3.         產生、輸出“錯誤”測試消息。
				E收到消息，帶有無效的Signture值	1.         發送Reject會話層駁回消息，參照無效的Signature值。（>=FIX4.2：SessionRejectReason = “簽名問題”） 2.         增加接收MsgSeqNum值。 3.         產生、輸出“錯誤”測試消息。 或者，考慮解密錯誤或順序錯誤的消息，忽略消息（不增加接收MsgSeqNum值）並繼續接收消息。
				F 收到消息，有有效的SecureDataLen和SecureData值，且能被解密爲有效的，能接戲的明文	接收消息。
				G 接收消息SecureDataLen值無效	1.         當做解密錯誤或消息順序錯，忽略消息（不增加接收MsgSeqNum值）並繼續接收消息。 2.         產生、輸出“警告”測試消息。
				H 接收消息帶有不能被解密爲有效、能被解析的明文	1.         發送Reject會話層駁回消息，參照無效的SecureData值。（>=FIX4.2：SessionRejectReason = “解密問題”） 2.         增加接收MsgSeqNum值。 3.         產生、輸出“錯誤”測試消息。
				I 接收消息中一個或多個域本應按規範不能被加密的，未出現在非加密部分	1.         發送Reject會話層駁回消息，參照不能加密的丟失域的Tag值。（>=FIX4.2：SessionRejectReason = “解密問題”） 2.         增加接收MsgSeqNum值。 3.         產生、輸出“錯誤”測試消息。
				J 接收消息有按照指定的Encryp他Method有錯誤的“left over”字符處理（如，當密文前的明文長度部位8的倍數時）	1.         發送Reject會話層駁回消息，參照錯誤的“left over”字符處理。（>=FIX4.2：SessionRejectReason = “解密問題”） 2.         增加接收MsgSeqNum值。 3.         產生、輸出“錯誤”測試消息
18		支持第三方尋址	可選	A 接收消帶有OnBehalfOfCompI和DeliverToCompID值，同測試Profile中指正確用法相符	接收消息
				B接收消帶有OnBehalfOfCompI和DeliverToCompID值，同測試Profile中指正確用法不相符	1.         發送Reject會話層駁回消息，參照無效的OnBehalfOfCompI和DeliverToCompID。（>=FIX4.2：SessionRejectReason = “CompID問題”） 2.         增加接收MsgSeqNum值。 3.         產生、輸出“錯誤”測試消息
19		測試PossResend處理	強制	A 接收消息帶有PossResend=‘Y’且應用層消息ID檢查顯示其已經在本次會話中出現過	1.         忽略該消息 2.         產生、輸出“警告”測試消息。
				B接收消息帶有PossResend=‘Y’且應用層消息ID檢查顯示其已經在本次會話中沒有出現過	接受並正常處理該消息。
20		同時Resend 請求測試	強制	當已經發送和等待一個Resend Request消息的所有響應後，接收到一個Resend Request消息	1.         執行請求被請求消息的重傳。 2.         發送Resend Request消息請求丟失消息重發。