理由
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会话中被使用。
)
