证券交易数据交换应用框架参考实例、FIX标准会话机制、消息、重复组实例、计算校验和.pdfVIP

GB/TXXXXX—XXXX 附 录 A （资料性附录） 应用框架参考实例 图A.1是证券交易数据交换协议应用环境的参考实例。 在该参考实例中证券交易数据交换协议用于市场参与者内部系统与市场参与者协议转换系统间的 连接、交易所交易系统与采用STEP开放接口的市场参与者系统间的连接，同时也支持外部交易所接口系 统与外部交易所的连接。 图A.1 应用环境实例 83 GB/T XXXXX—XXXX 附 录 B （规范性附录） FIX标准会话机制 B.1 FIX会话 B.1.1 消息序号 任何一条消息都被分配有一个消息序号来唯一标识，消息序号在每次会话过程中从1开始，在整个 会话过程中连续递增，直到该会话过程全部结束。通过监视消息序号的连续性可以知道交换中的消息缺 口，并做出反应，使得连接双方数据同步。 连接双方都明确确定相互独立的消息序号，参与连接的任何一方负责维护自己发送的消息序号，并 监视接收的消息序号以保证消息缺口的发现和处理。 B.1.2 心跳 在消息交换的空闲期间，连接双方将会产生有规则的心跳消息。通过心跳消息可以监控通讯连接的 状态。心跳间隔时间由会话发起人在登录时确定。在发送任何消息后，应立即重新设置心跳间隔计时器。 心跳间隔时间应该得到连接双方的确认，由登录发起人给出并得到登录接受方的确认。连接双方使用相 同心跳间隔时间。 B.1.3 缺口填补 由于协议是基于乐观的消息传输模式，消息在传输过程中可能存在丢失，而这种消息丢失发送方不 能检测，因此接收方应负责检测消息的缺口并处理。有两种处理方法：接收方发现缺口后向发送方请求 发送缺口消息及其后的所有消息；接收方发现缺口后，保存已收到消息，并向发送方请求重复发送缺口 消息。 B.1.4 消息重复发送 响应一个重发请求而重复发送消息时，或者不确定对方是否收到某消息而重复发送该消息时，应在 该消息内加上可能重复标志 （PossDupFlag Y）。如何处理该消息则是接收方的事情。由于当生成有此 类可能重复发送的消息时，仍使用该消息的原来序号，但某些信息可能会改变，如原始时间、发送时间、 正文长度、可能重复标志等，所以应重新计算校验和。 B.1.5 消息重新发送 基于应用层的可能重发，如发送的订单在相当长的时间内没有确认，或者怀疑其根本未曾发送过， 可以通过设置可能重新发送标志来重新发送(PossibleResend Y)，并使用新的消息序号。接收方应用层 收到该类消息后，应通过查询消息内的域 （如订单编号等）来确定此前是否收到此条消息。该类消息应 确定包含相同的正文数据，同样，由于某些信息可能会改变，所以应重新计算校验和。 B.1.6 消息确认 由于协议是基于乐观的消息传输模式，通过监视消息序号发现缺口，不支持对每个消息收发的确认。 但大量消息收发的确认可在应用层定义。在应用层接受和拒绝是允许的，如订单的确认。 84 GB/TXXXXX—XXXX B.2 FIX连接 B.2.1 FIX连接概述 会话过程的数据交换可以这样描述：连接双方各有一个连续的消息序号随消息传送，而交易期间可 以多次断开并重新连接，其断开可以是外因引起，也可以是连接双方根据系统来统一制定何时断开并重 新连接。一次会话连接通常不应超过24小时，当然，如需要保持24小时以上的连接，则需要发送一条含 有序号重设标志的登录消息来建立新的起始消息序号。 FIX连接分为三个部分：登录、消息交换、注销。 FIX会话包含一个或多个FIX连接，即一个FIX会话可以跨越多个登录。 B.