理由
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 额外的实现细节
与实际商业的多播环境下的更多的实现细节应由参与方制定相关文档，并达成共识。