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標記域的分界符每個字元的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 ConnectionFIX連接 由3部分組成：logon登錄，message exchange消息傳輸，和logout註銷。

FIX SessionFIX 會話 由一個或多個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消息和一些描述性文本應被發送給對端。

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為買方

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=第三方。

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

標準消息頭部如下

Standerd Message Header

4.7 Standard Message trailer標準消息尾部

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

Standard Message Trailer

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

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

5.3 Test Request 測試請求消息

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

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

測試請求消息格式如下：

Test Request

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

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消息將被發出。

會話級駁回消息場景：

駁回消息格式：

Reject

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

5.7 Logout註銷消息

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

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

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

註銷消息格式如下：

Logout

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會話層狀態舉證

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

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