金融信息交换协议（FIX）5.0 FIXT1.1（2）

 

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确认消息后，发送一个ResendRequestLogout

如果一个消息间隙被检测到，在确认Logout消息发送之后再发起一个ResendRequest以补偿所有丢失消息。不要终止会话。Logout消息的发起方负责终止会话。这样可以允许Logout发起者对任何ResendRequest消息进行响应。

如果是Logout的发起方，那么这是一个Logout确认消息，必须在收到之后立即终止会话。

唯一一个“不终止会话”的例外是无效的Logout尝试。会话接收者有权发送一个Logout消息并立即终止会话。这样可以减少未经授权的连接尝试。

ResendRequest首先执行重传处理，接着按照自己的顺序发送ResendRequest消息用以填充接收消息间隙。SeqReset-Reset忽略接收序列号。SeqReset消息的NewSeqNo将包含下一个传送消息的序列号。SeqReset-GapFill发送一个返回ResendRequest。间隙填充消息行为与SeqReset消息相似。然而，确认没有消息被连续地跳过是非常重要的。这意味着GapFill消息必须按顺序接收。一个无序的GapFill消息时则表明一种异常情况。所有的其他类型消息执行间隙填充操作。

原文转自：http://blog.csdn.net/songzhang/article/details/1800181