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

 

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会话层状态举证

Precedence 次序	State 状体	Initiator 发起者	Acceptor 接收者	Descriptioin 描述
1	断开 当天未连接	Y	Y	当前处于断开状态，当日未进行连接尝试。没有MsgSeqNum被使用（下一个当日的连接的MsgSeqNum值为1）。
2	断开 当日开始连接	Y	Y	当前处于断开状态，尝试建立当日连接，这样，MsgSeqNum开始被消耗（下一个当日连接时，MsgSeqNum将从其（last+1）开始）
3	检测到网络连接的中断	Y	Y	处于连接状态时，检测到一个网络连接中断（如TCP socket关闭）。断开网络连接并关闭该会话的配置。
4	等待连接	N