理由
FIX協議由一個會話層協議，一個應用層協議和一套域數據字典組成。后兩者不依賴于FIX會話。而且，由于FIX會話作為Point-to-point（點-對-點）通信，并不適合于發布/訂閱模式（如為大量接收者提供市場數據）。本應用注釋文檔定義了FIX消息怎樣通過多播傳輸技術（如，IP多播）進行發布。此注釋并不描述具體的多播技術，而是討論如何修改FIX回滬協議以使用該技術進行通信。
會話層概述
為保證在一個多播環境中正確檢測消息間隙，除了在下面提到的，一個特定的主題，應只有一個發布者。在本文中，“主題”指的是接收者如何偵聽及偵聽的對象，以及發布者如何通過它發送信息（如，主題明，TCP偵聽端口，等等）。多播技術及其實現的特征（如發布者使用一個主題接收從多個接收者發來的重傳請求）將控制是否由一個特定的發布者發送的消息能按照順序進行傳送。一個特定的主題可以有任意數量的訂閱者或接收者。
為了檢測在會話中存在的消息間隙，在每個消息中的序列號應基于每一個主題進行賦值。如果不這樣做，接收者（沒有訂閱所有主題）將無法檢測到消息實際存在的消息間隙。這樣，接收者必須為每個主題維護一個期望的序列號。
與標準的FIX會話層協議不同（FIX4.0或更高版本），所有的管理消息將不占用序列號（同FIX3.0一樣）。在多播環境下的數據傳輸類型是單向的（從發布者到接收者），這樣將不會出現在雙向FIX3.0會話中可能存在的競爭。這樣，FIX4.0及后續版本中對管理信息占用一個序列號的需求可以忽略。在這樣的情況下，管理消息應包含下一個發送消息的MsgSeqNum而不是占用活增加MsgSeqNum的值。任何發送的會話層消息應增加下一個發送序列號，使得接收者可以檢測消息間隙，并至此執行消息間隙處理。
在所有消息中的TargetCompID應設置成一些預先定義好的值（由發布者賦值），如消息發送所基于的主題名。在所有消息中的SenderCompID應設者為預先定義的，由發布者賦值的，用于識別發布者身份的值。
Logon 登陸消息
同通常的雙向FIX會話登陸不同，在發布/訂閱或多播環境下的登陸應采用從發布者到訂閱者的單向方式。用于通知訂閱者，發布者會話已經開始。
Heartbeats 心跳消息
Heartbeat消息作為在應用消息交互期間保持鏈路活動測試包使用。Heartbeat消息應只能由發布者發送。
Resend Request
如果接收者在發布者發送的消息中檢測到一個序列號間隙，它可以通過另一個定義好的Resend Request主題發送一個Resend Request消息。當發布者接收到一個Resend Request消息，可選擇立即響應、定時響應或根本不響應該請求。由于Reject消息不在多播環境中使用，發布者應忽略無效的Resend Request（如：序列號過大火重復消息）。如果在響應一個Resend Request時，發布者希望跳過一個或多個消息，它應發送一個Sequence Reset/Gap Fill消息用于提示這個間隙應自動填充。由于發布者可能不立即響應，接收應用程序應細細考慮是否為了順序傳遞應延遲處理后續消息。
如果要發布多個應用主題，應為每個應用主題定義一個單獨的Resend Request主題。為了使應用主題發布者識別請求的主題，Resend Request消息應通過TargetSubID域明確所期望的應用主題。此外，也可以建立一個單獨的主題，讓接收者在主要的主題外偵聽Resend Request響應。
一些多播技術（如：IP多播）不允許發布者響應一個特定訂閱者的重傳請求，也不提供通過主要的主題分發通道對所有訂閱者進行同樣的響應。訂閱者必須具備忽略比期望序列號小的消息的能力。
Rejects駁回消息
在此模式下，會話層駁回消息將不再使用。
Logout注銷消息
同通常的雙向FIX會話注銷不同，在多播環境下的注銷應采用從發布者到訂閱者的單向方式。用于通知訂閱者，發布者會話已經結束。
Additional Implementation Details 額外的實現細節
與實際商業的多播環境下的更多的實現細節應由參與方制定相關文檔，并達成共識。
多播傳輸技術通常被認為在分發大批量相同數據到大量接收者的一種非常有效的方式。在提供重要交易數據服務的金融組織中，該技術被廣泛使用。
IP多播網絡提供一個支持將IP數據包轉發給一組在多個位置的接收者的機制。IP單播網絡支持將IP數據報發送給一個特定位置的單個接收者，而IP廣播則支持將IP數據包發送給一個特定位置的所有接收者。
IP多播網絡優勢的本質在于一個單一的IP數據包可以由一個服務產生，然后被轉發給一組感興趣的接收者。這種方式即優化了應用又優化了網絡資源。
由于應用服務器只需對所有的接收者產生一個單一的數據包，服務器容量及執行效率不再受到接收者數量增長的影響（這將影響CPU，內存，網絡連接等資源），并且應用服務器不再需要考慮維護會話的開銷。同樣，由于只有一個單一的數據包需要通過給定的路徑轉發，那么這些應用數據流發送的網絡帶寬將會減少。
在結構上，實際的標準網絡協議模式是一個稀疏模型模式，數據通過網絡到感興趣的接收者所捆綁的網絡設備間進行多播。與推送模式相關的稠密模型模式已經逐漸被淘汰。
作為優化交易數據各方面工作的一部分，FIX正致力于將其規范擴展到多播傳輸技術和交易數據傳輸的應用領域。在研究多播數據傳輸的行業機構的協助下，提出了后面的推薦方案。
Multicast Configuration 多播配置
IP多播在傳輸層使用UDP協議，應用數據被封裝在一個個IP|UDP數據楨中。
當一個服務器能夠很容易地發送淹沒網絡貸款的突發數據的時候，突發控制就至關重要。所有的多播源應當具備某種使其網絡帶寬能夠受控使用的調步（由接收站來控制發送站的傳輸速率以避免超速或堵塞的一種技術）機制。
由傳輸設備將需要發送的數據進行邏輯分節是行業的通常做法。然后，這些數據通過一個公認的UDP端口號和一個多播組地址進行傳輸。這就具備了創建分離的數據通道或鏈路的效果。
數據通道和數據鏈路的創建引入一種分級的服務間隔粒度，能夠用于創建產品集以及允許共享處理消耗。
然而，太多的間隔粒度將引入網絡和其他處理的消耗（例如，將會導致大量的多播組的存在）。所以，在對數據進行分節的時候，注意將多播組的數量保持在一個適當的最小數量。
在多播分劃中的一個關鍵問題是組攪動（？）。任何允許客戶訂閱/退訂分隔粒度太好的組消息的模式反而起不了好作用（如一個股票代碼一個組）。分組大小和網絡帶寬占間得有個取舍。太多分組占用太多帶寬，而分組太少沒有達到分劃的效果。
因此，通常的實踐是采取一種引入適當分隔粒度進行內容的邏輯分組，采取允許數據能夠通過相對平均地跨越傳輸通道進行共享數據的方式進行分組。典型的，包含信息內容（如，證券、期權）和數據量（如一組“A到D”的工具集）？？？？。
為了給應用服務提供商，網絡服務提供商及訂閱者的集成提供便利，使用全球唯一的IP源和目標地址是做好的做法。
對單播IP源地址而言，將會是一個在IANA組織登記的IP地址或對應用或網絡服務提供商登記的適當IP地址。對多播目標多播分組地址而言，應用服務提供商應僅使用由IANA或遵循RFC3180的地址。
優化網絡和服務資源，通過將多個消息打包圍當個的數據包以最小化開銷被認為是目前最好的習慣（實踐）。這就要求應用程序在某個（最小的）有效時鐘周期期滿內傳送一個數據包，在時鐘周期結束前，數據被完整打包。
被傳送的數據包應在一個絕對的范圍內能被唯一識別，并且這些包應不被它們彼此的關系參照，這也被認為是當前做好的做法。這就使對方問一個特定
考慮應用程序生成的數據包大小。正如上面提到的，推薦在每個包中承載多個消息，以優化處理和轉發。然而，一般而言，推薦包的大小不要超過MTU大小，小于1400字節。這也是網絡封裝發生時必須的。？？？？
Live/Live Configuration
IP數據包（在特定的環境下）在傳輸過程中可能會發生順序混亂、重復或丟失。類似IP，UDP是面向無連接的協議，它不提供類似于TCP協議那樣的確保不丟包或不發生數據包順序混亂的機制。由此，應用程序應負責管理數據亂序，重復數據包和數據包丟失。
加入多播組的應用程序接收到多播數據包時應能處理重復的和亂序的數據包。
應用服務提供商應用各種機制為多播應用提供重傳服務。此外，應用服務提供商采用常見方法/機制減少訂閱者沒能接收到數據包的風險。
該方法就是復制每個數據包然后通過另外的通道（多播組|UDP端口）進行傳輸。這些通道能通過單獨的物理網絡架構進行傳送，以擴展多樣性和減少丟包的風險。其目的是期望數據的訂閱者或接收者應對兩個通道進行偵聽，并負責在兩者之間進行判斷以構建一個單一的集合。
Channel Grouping and Definition 通道分組和定義
應該盡量注意將通道數保持在一個適當的最小數量。作為實際的例子，對于一個總數為20個通道Live/Live配置的情況下，大約需要10個主要的通道。對通道數的限制的一個原因是可能會導致全球唯一多播ID的缺少，多播僅擁有一個有限的IP地址范圍。許多因素在確定通道數時需要去考慮。比如，傳輸數據量的大小是一個決定因素，我們不能期望10個通道僅有1Kbi/s的數據傳輸率。
通訊通道ID
當前好的實踐是將分組、端口等的定義進行分離，從實際的轉發機制中構建一個通道。
因此，不鼓勵在消息數據內容部分包含IP地址信息（包括多播組地址）。將這些地址從消息數據內容中分離出來也提供了在IP或UDP地址使用方面的伸縮性。
為支持該方法，一個推薦的方法應被用于產品定義和屬性的傳輸，例如：其產品符號在多播組地址中可用。？？？
Multicast Session Layer 多播會話層
這個部分討論當通過多播技術傳送市場數據時使用的會話層控制。通常，在使用一個多播范列中推薦使用一個輕量級FIX會話層。然而，這里仍然有幾個會話層控制對于管理一個多播會話是有用的。
Entitlement授權?
如果通道用戶直接連接到供應商的分發網絡，其授權可以由供應商在網絡邊界的PIM過濾或IGMP控制機制來控制。該授權行為可以替代一個登陸驗證。但該方法不能用于用戶沒有直接連接到供應商控制的網絡，比如Intenet。為了對模板交換以及在發送者到接收者間使用消息類型進行的通信產生影響，一個單獨的會話層登陸是必要的。簡而言之，一個顯示的由接收者發起的注冊一個通道或一組通道的登陸不是必須的。
Sequnce Gap Handling 序列號間隙處理
由于幾個原因，在多播場景里，與常規的FIX序列號間隙處理相比，間隙處理將有不同。首先，對于潛在的序列號丟失，Live/Live配置要求質詢雙方的反饋？。序列號間隙處理仍然能被執行，但其算法必須診斷是否消息序列號是否存在于每一個反饋中。其次，由于可靠性的問題，不推薦通過多播會話創建重傳請求。在每一個反饋中，如果序列號不可用，那么對丟失數據的重傳帶外請求可以使用一個重傳請求消息創建。推薦使用一個單獨的、使用TCIP-IP協議的的會話連接用于提供重傳請求的可靠傳送。
通過重傳請求消息發起的重傳請求，必須指定所請求消息傳輸的原始主通道。單獨的開始和結束序列號是不夠的，應為不能保證在所有通道中的唯一性。注意，既然通道的ID是一個主體，那么要改變它們應當在Resend Request消息中創建一個可配置的參數。
Heartbeat心跳
心跳信號用于接收者判斷連接的是否仍然活躍。心跳消息必須在每個通道中傳送，并攜帶消息序列號（MsgSeqNum/Tag為34）。每個通道將有其自己的一套序列號，并且在通道中保持唯一，而不是在所有通道中保持唯一。MsgSeqNum能用于接收者驗證feed的完整性。如果心跳消息中的MsgSeqNum等于接收者期望接收的下一個序列號，那么feed是完整的。否則，表明feed已經被破壞，此時需要創傳或重新連接。
Time Beacon 時間信號燈
時間信號燈消息同HeartBeat心跳信號的有大致形同的作用，用于通告一個通道的活動性。然而，時間信號燈，并不攜帶下一個希望接收的序列號。
Retransmission of Data
由于UDP是不可靠的，無連接的數據報傳輸機制，因此應用層應負責處理數據包的重復接收，亂序，和丟失。注意，就包轉發而言，TCP和UDP都會因此受到影響。
因此，即便是在LIVE|LIVE這樣的多播傳遞機制里，多數分發關鍵數據的應用也支持重傳機制。
現在，有多種不同特征的重傳機制正在進行使用。
事實上，所有這些機制都使用一種“帶外”請求機制。帶外請求機制被認為是最好并推薦的機制用于使用TCP/IP單播請求模式。基于帶內多播的請求則不提倡。
在這種模式下，接收者主機設備將同合適的應用服務提供設備（可以是也可以不是發布多播數據流設備）建立TCP會話，并請求一個或一定范圍的數據包的重發。
被請求重發的數據包可以通過多種途徑進行傳輸：1，使用主要的|多播創建組進行重發；2，數據包由TCP/IP單播會話返回；3，數據包由單獨的當做重傳組進行傳輸。
推薦使用第3種可選方案，在此，一個或多個分離通道獨立于主要的數據生產轉發機制被采用，這樣仍然可以保持多播的高效率。
多數情況下，當這種模式被采用時，也存在多個多播重傳組。如果存在多個組，那么當前最好的實踐是將每一個重傳組同數據內容關聯起來。
Retransmission Channels
推薦運用IP多播來實現重傳機制的數據包重傳。而且，推薦重傳的數據包不應在原始數據包傳輸的通道上進行傳輸。
因此，盡力一組重傳組，使得期望，或需要接收重傳數據的參與這可以加入到其中接收數據。然而，一般而言，期望應用重傳機制的參與者通常能加入其特別需要專注的重傳組。
重傳應總是通過單獨的，專門的目的通道進行。一般而言，這里應該有一個單獨得通道，發布所有的重傳數據。在一些通道連接狀態下，一個邊界路由將靜態的腳如通道，一位著該通道將總是注意活動狀態，并且訂閱數據源。這個配置具有簡單的特性，在這種情況下，所有的重傳數據經總是通過一個單獨得通道接收。
這種方式的一個小的卻缺陷是沒有優化使用帶寬。重傳通道將加載被所有交易參與這請求的數據，不僅僅是接收者偵聽的數據。一個可能的替代方案是：在需要重傳時連接通道，不需要是則斷開。
另一個可能的替代方案是建立多個重傳通道，也許是一個主通道就有一個重傳通道。這個方法的優點在于接收者可以知道那個數據生成組通過給定的重傳通道被接收。缺點則是對保持一個合理的最小數量通道與多播基礎設施的增長存在沖突。因此，這個方案不值得推薦。
Application-Level Requests for Retransmission
應用級重傳請求經通過Market Data Request消息進行支持。建議重傳請求通過一個可靠的請求傳遞的TCP/IP連接來實現。由請求響應得接收者負責消息接收的確認。為擴展請求的執行有效性，Market Data Request Reject消息能由請求響應者發起，并攜帶“不能處理”和指明拒絕的理由的響應。
一個重傳請求一般由以下幾個情況下被創建：
l???????在指定了開始和結束時間標簽的一個時間范圍
l???????通道ID
l???????責任
l???????Book的當前狀態
注意，Market Data Request應不請求消息序列號的重傳，它在會話層自動被執行。
Multicast Entitlement
使用IP多播技術支持數據發布的常用架構模式是一種單向模式，在此模式下，應用服務提供者發布數據，訂閱者則在網絡層訂閱其需要的數據。
因此，通常當前存在非點-對-點，雙向的應用層通訊以支持登錄序列交換能夠用于驗證訂閱者是具備接受發布數據的權限。多播不是最好的任意定制接收技術。
因此，一個受信網絡提供者（可能是應用服務提供者，或單獨的網絡服務提供者）應負責在網絡層提供一種認證模式。
在非受信的網絡中，必須使用數據加密。然而，數據加密通常不在多播交易數據傳輸中使用。通常，除非數據在非受信網絡，比如Internet上進行數據傳輸時，數據加密通常是沒有必要的。由私密專用鏈路或私密外聯網提供的安全性將產生額外的由不易察覺的數據加密引入的延遲。
認證模式最主要的目標應該是提供：1、多播發布數據的安全傳輸，也同時保證發送者是經認證的；2、數據只分發給受信的接收者。
多播認證為發送者提供了一個數據安全層。只有核準的數據接收者可以加入到一個通道中。它不為發送者提供保護其內部資源的安全，但它協助確保只有核準的接收者獲得通道數據。靜態配置（Static Configuration）決定誰能夠加入到一個通道中。接收者必須在發送者的路由里進行設置，使其能加入到一個多播通道中。
PIM Filters PIM過濾器用于在路由器上提供認證。不必進行LDAP查詢或其它驗證。
IP多播的特性在于消除了那些在單播傳輸中的機制，用于認證請求者，并且這里不存在業界普遍認可的替代方式。因此，最常采用的方式是運用網絡層，在邊界設備中實現，確保數據僅分發給核準的接收者。
Message Header 消息頭部
這個部分討論FIX消息頭部，及其在多播環境中的應用。FIX頭部，作為應用消息的一部分進行傳輸，與多播頭部不沖突，多播頭部指定了其他的一些數據，如發送者的IP地址。由于多播是廣播，與單播傳輸不同，消息能夠使用FIX頭部的部分域來創建就足夠。
在多播環境中，最少應包含BeginString，MsgType，MsgSequNum和BodyLength域。 當前的FIX規范要求提供SenderCompID和TargetCompID。然而，這些域在多播環境會話中將失去作用，只是在點—對—點會話中有用。
當消息被作為一個Resend Request消息的響應被傳送時，被重傳的消息可以選擇攜帶PosDupFlag域，該域在標準的FIX會話中被使用。
)
