FIX协议结构及工作流程(转)

转自: http://blog.sina.com.cn/s/blog_8687b64201014dnw.html

Fix 协议可以分两大部分，会话层协议和业务层协议。会话层定义了数据通信相关的协议，业务层定义了金融活动相关的业务数据结构。 Fix 的会话层设计时候充分考虑了稳定性，安全性，健壮性，高效性。稳定性指会话协议中定义了心跳消息来维护会话连接，安全性指协议从消息结构上支持数据加密，出错重传指每个会话在两个端点各自维护一套消息序列号，防止消息丢失，漏发漏收，出现这种情况只要检查两边序列号的连续性就可以确定需要重传哪些消息。

1. session 的通信各方维护一个 incomming 和 一个 outgoing 序列号。 Incomming 序列号用来检测序列号是否乱序或跨越。
2. 心跳在 initiator 发送 logon 消息时候设置在心跳域上， acceptor 和 initiator 的心跳间隔时间一致。
3. Fix 消息要按序列号从小到大顺序处理，若收发过程中出现丢包则有两种策略：重传序列号出错的包及以后所有收到得包；另一种是只重传出错的包；
4. Fix 协议没有定义应答消息，使用序列号不连贯来检测消息丢失，用 checksum ，签名或消息体长度来检测消息错误；
5. Logon 阶段，客户端选择了了一个加密密钥，但服务器选择了不同的密钥放在返回的 logon 消息中，这时候客户端还得发一个 logon 消息应答服务器端，两个作用： 1). 让服务器知道密钥变更获得了客户端的响应； 2). 下面的消息开始要加密了。
6. 在 logon 阶段完成后必须马上检查序列号，同步收发的消息，比如一端发送了消息但另一端没收到，这时候需要重传。可以通过对比 logon 消息中的序列号和通信一方的期望收到的消息序列号来检测消息漏收发。
7. 序列号最好每隔 24 小时重置一次，重置前要商量好哪一方来首先发送重置请求及发重置请求的时间。重置之前要一方首先发送 testrequest 消息，等待收 heartbeat 消息来确认连接是否正常，然后才发送 logon 消息，并把消息中的序列号重置域设为 Y ，并且序列号置为 1 ，接收方回复同样消息，重置成功；

1. Logout 之前需要发送 testrequest 消息强制心跳，检测消息序列号是否连续， logout 消息发送出去之后，需要等待一段时间接收 logout 回应消息，这段时间让双方来处理序列号不一致的问题，一旦序列号同步之后 logout 接收者马上发送回应的 Logout 消息， Logout 发起方收到回应后负责来关闭会话。
2. Fix4.4 中在 logon 消息中加入了 NextExceptedSeqNumb 域，用来表示本方期望对方发过来的下一个序列号，这样 logon 阶段完成后直接就是漏发消息的重发，不需要再发送 testrequest, heartbeat 和 ResendRequest消息了。
3. possResend 和 possDupFlag 区别就是前者使用了新序列号发送老的消息，可以通过检查消息中的域来确定是否已经收到过改消息，比如 order 的 ID 等；后者是用老的序列号重发消息，可以直接检查序列号来确定是否已经收到过该消息，若已收到过了就丢弃该消息。
4. logon 消息中有两个字段 RAW Data Length 和 RAW data 用来存放认证需要的数据。