关于fix

25 January 2015

前言

工作需要，需要研究一下Fix，有空的话，着手调查一下吧。

导读:不少协议的使用都给我们带来了巨大的便利。 这个我想也是互联网的最大的特点了。 那 么我们现在要介绍的就是 FIX 协议。 那么这个协议的具体应用特点我们就来详细说一下。

Fix 协议可以分两大部分，会话层协议和业务层协议。 会话层定义了数据通信相关的协议，业务层定义了金融活动相关的业务数据结构。 Fix 的会话层设计时候充分考虑了稳定性，安全性，健壮性，高效性。稳定性指会话协议中定义 了心跳消息来维护会话连接，安全性指协议从消息结构上支持数据加密，出错重传指每个会 话在两个端点各自维护一套消息序列号，防止消息丢失，漏发漏收，出现这种情况只要检查 两边序列号的连续性就可以确定需要重传哪些消息。 session 的通信各方维护一个 incomming 和 一个 outgoing 序列号。Incomming 序列号 用来检测序列号是否乱序或跨越。 心跳在 initiator 发送 logon 消息时候设置在心跳域上， acceptor 和 initiator 的心跳间隔时间一致。 Fix 消息要按序列号从小到大顺序处理，若收发过程中出现丢包则有两种策略：重传序 列号出错的包及以后所有收到得包； 另一种是只重传出错的包； Fix 协议没有定义应答消息， 使用序列号不连贯来检测消息丢失， checksum， 用 签名或消息体长度来检测消息错误； Logon 阶段， 客户端选择了了一个加密密钥， 但服务器选择了不同的密钥放在返回的 logon 消息中， 这时候客户端还得发一个 logon 消息应答服务器端，两个作用： 1). 让服务器知道密钥变更获得了客户端的响应； 2). 下面的消息开始要加密了 在 logon 阶段完成后必须马上检查序列号， 同步收发的消息， 比如一端发送了消息但另 一端没收到， 这时候需要重传。 可以通过对比 logon 消息中的序列号和通信一方的期望收到 的消息序列号来检测消息漏收发。 序列号最好每隔 24 小时重置一次， 重置前要商量好哪一方来首先发送重置请求及发重置 请求的时间。重置之前要一方首先发送 testrequest 消息，等待收 heartbeat 消息来确认 连接是否正常，然后才发送 logon 消息，并把消息中的序列号重置域设为 Y，并且序列号置 为 1 ， 接收方回复同样消息， 重置成功； Logout 之前需要发送 testrequest 消息强制心跳， 检测消息序列号是否连续， logout 消息发送出去之后，需要等待一段时间接收 logout 回 应消息，这段时间让双方来处理序列号不一致的问题，一旦序列号同步之后 logout 接收者 马上发送回应的 Logout 消息， Logout 发起方收到回应后负责来关闭会话。 Fix4.4 中在 logon 消息中加入了 NextExceptedSeqNumb 域，用来表示本方期望对方发 过来的下一个序列号，这样 logon 阶段完成后直接就是漏发消息的重发，不需要再发送 testrequest, heartbeat 和 ResendRequest 消息了。 possResend 和 possDupFlag 区别就是前者使用了新序列号发送老的消息，可以通过检 查消息中的域来确定是否已经收到过改消息， 比如 order 的 ID 等； 后者是用老的序列号重 发消息，可以直接检查序列号来确定是否已经收到过该消息，若已收到过了就丢弃该消息。 logon 消息中有两个字段 RAW Data Length 和 RAW data 用来存放认证需要的数据；FIX 协

议在具体的实施中已经就一些业务流程进行了规范，考虑到世界各地业务模式的差异和应用 环境等不同，FIX 委员会也留给了实施者相当大的回旋空间，在这个空间内实施者可以定义 特殊的应用需求。 在 FIX 协议包含两个层面（会话层和应用层）中，会话层主要任务是信息 交换双方的连接建立及保持、信息交换过程中的安全性、完整性和一致性，具体实施中，由 于会话层对如何实现已经有了明确描述，实现起来相对容易。 应用层定义了具体的业务接口，同时也包含了在这些业务接口中的业务逻辑。所以，对 应用层业界有多种看法。首先 FIX 协议应用层是一个标准的接口，这个接口可以用来定义机 构之间（券商与券商、券商与交易所等）或机构内部的应用业务接口。其次它又不仅仅是一 个接口。在这些应用层信息之间，包含着很明确的业务逻辑。我们可以这样认为，FIX 协议 是一个带有一个会话层应用接口。所以，FIX 协议的实施，不仅是接口的统一规范，同时需 要将业务逻辑延伸到信息交换的过程当中。通常，FIX 协议的业务逻辑是通过 FIX 引擎（FIX Engine）来实现的。FIX 引擎的主要功能是根据业务需求，生成相应的业务请求（信息） ，以 点对点（可以经由第三方）的方式，最终将交换信息送达目标 FIX 引擎；同时 FIX 引擎对接 受的信息进行解析，在此基础上，生成相应的应答信息。信息的解析过程，实际上是业务逻 辑的实现过程。 它的任务是将 FIX 协议应用层接口所需的域信息从信息库中取出，按 FIX 协议所要求的 信息格式打成数据包，然后提交。首先，撇开 FIX 引擎会话层属性，在应用层，FIX 引擎具 有上述特性；其次，FIX 引擎在处理信息过程中是一个交互的过程，除原始的请求和广播信 息外，FIX 协议的应答信息按照信息之间的业务逻辑生成数据包，在数据包生成过程中，同 时会伴随其他相关的信息交换，如一个订单信息（Order-Single） ，它是在证券信息/行情信 息/报价信息（IOI 信息）等信息交互过程中而生成的；再次，在信息交换过程中，FIX 引擎 会遵循 FIX 协议的域、信息类型定义、数据字典约定以及相应的信息定格；最后，FIX 引擎 还会对信息交换双方的自定义域和信息类型进行约定，这些约定会完整地贯穿于整个信息交 换过程中。

参考资料:

  1. http://en.wikipedia.org/wiki/Financial_Information_eXchange
  2. http://www.fixtradingcommunity.org

后记



傲娇的使用Disqus