FIX协议介绍与QuickFIX使用入门(上)

定义

FIX协议是由国际FIX协会组织提供的一个开放式协议,目的是推动国际贸易电子化的进程,在各类参与者之间,包括投资经理、经纪人,买方、卖方建立起实时的电子化通讯协议。

FIX协议的目标是把各类证券金融业务需求流程格式化,使之成为一个个可用计算机语言描述的功能流程,并在每个业务功能接口上统一交换格式,方便各个功能模块的连接。

FIX协议各个版本对股票、期权和期货的支持程度,目前市场上使用FIX4.4的较多。

FIX协议介绍与QuickFIX使用入门(上)_第1张图片

FIX通信模型

  • Initiator:发起者,建立通信连路,通过发送初始Logon消息发起会话的参与方。
  • Acceptor:接收方 FIX会话的接收方。负责执行第一层次的认证和通过传输Logon消息的确认正式声明连接请求被接受。
  • 原则:先发起者为Initiator ,接受者为Acceptor 。
  • 标准模式以网关为Acceptor,客户端为Initiator做为常用模式。

基本概念

FIX Connection

FIX连接 由3部分组成:logon登录,message exchange消息传输,和logout注销.

FIX Session

FIX会话由一个或多个FIX Connection FIX连接组成。一个FIX会话可以有多次登录。一个FIX会话定义为一个在连接双方间的的带有连续序列号的有序消息双向传输流。 单个FIX会话能够跨越多个连续(不是并行的)的物理连接。在一个维持的,单独的FIX会话中,参与方能够多次连接和断开连接。连接的参与方必须根据单个系统及时间区域需求,公共协商会话的开始和结束。无论什么原因,重新设置接收和发送序列号为1,意味着一个新的FIX会话的开始。

建议一个新的FIX会话在每24小时期间建立一次。可以维持24小时的连接和通过设置在Logon消息中的ResetSeqNumFlag建立一套新的序列号。

Sequence Num

所有的FIX消息都由一个唯一的序列号进行标示。序列号在每一个FIX会话开始时被初始化为1,并在整个会话期间递增。监控序列号可以使会话参与者识别和处理丢失的消息,当在一个FIX会话中重新连接时能够优雅地进行应用程序同步。每个会话将建立一组互不依赖的接受和发送序列。会话参与者将维护一个赋予发送消息的序列和一个监控接受消息的消息块间隙序列号。

心跳 Heartbeats

在消息交互期间,FIX应用程序将周期性产生Heartbeat心跳消息。该心跳消息可以监控通信链路状态及识别接受序列号间隙。发送Heartbeat的周期间隔由会话发起者使用在Logon消息中HeartBtInt域进行定义。Heartbeat心跳消息的时间间隔应当在每一个消息发送后复位,即发送一个消息后,在间隔给定的时间内无其它消息发送则发送一个Heartbeat心跳消息。HeartBtInt的值应当被会话双方认同,由会话发起方定义并由会话接收者通过Logon消息进行确认。同一个HeartBtInt被会话双方——登录的发起者和登录的接受者共同使用。

Ordered Message Processing

FIX协议假设消息在所有参与者间完全按照顺序进行传输。协议的实现者在设计消息间隙填充处理时应当考虑这个假设。有两种方式处理消息间隙。每一个都要求所有的消息时最后一个接收消息的后续消息或在维护一个所有新消息有序序列时,请求特定丢失消息。比如:接收方丢失了5个消息块中的第二个,程序能忽略第3到第5个消息,产生一个对消息2到消息5的重传请求,或者从消息2到无穷大消息编号的重传请求。另外的方式是暂时存储消息3到消息5,仅要求重传消息2。对于这两种方式,消息3到消息5都不应该先于消息2进行处理。

Possible Duplicate

当一个FIX引擎对一个消息是否成功地被指定的目标接收或者当对一个重传请求进行响应时,将会产生一个可能的消息复制。这个消息将用同样的序列进行重新传送,此时在头部的PossDupFlag域将会被设置为‘Y’。接收端程序负责处理该重发消息,可以作为一个新消息进行处理,或者根据实际情况忽略该消息。所有重传请求的响应消息都将包含其值为‘Y’的PossDupFlag域。没有PossDupFlag域或者PossDupFlag域为‘N’的消息应被当作初始传送消息。注意,一个PossDupFlag值为‘Y’的重传消息需要重新计算其CheckSum值。一个可能的复制消息里发生变化的域包括:CheckSum,OrigSendingTime,SendingTime,BodyLength和PossDupFlag。加密相关域(SecureDataLen和SecureData)也必须被重新构造。

Possible Resends

模糊的应用层消息可能随同PossResend标志被重传。当一个指令没有在规定时间长度内进行确认或者终端用户挂起该指令没有进行传送时这种方法非常有用。接收程序必须识别此标志,并质疑其内部域以确定该指令是否在之前已经被接收过。注意,可能的重传消息将包含与原始消息相同的数据体,但包含PossResend标志和一个新的序列号。此外,CheckSum和与加密相关的域值需要重构。

数据完整校验 Data Integrity

消息数据内容的完整性可以参用两种方式来验证:消息长度和效验码检查。程序通过计算BodyLength域到(并包含)在CheckSum标记(“10=”)后的分界符的字符数与在BodyLength中标示的消息长度进行比较来完成完整性效验。ChekSum完整性检查,通过计算从域“8=”中“8”开始,包括紧跟在CheckSum标记域的分界符每个字符的2进制和同CheckSum进行比较得到。

消息确认 Message Acknowledgements

消息数据内容的完整性可以参用两种方式来验证:消息长度和效验码检查。程序通过计算BodyLength域到(并包含)在CheckSum标记(“10=”)后的分界符的字符数与在BodyLength中标示的消息长度进行比较来完成完整性效验。ChekSum完整性检查,通过计算从域“8=”中“8”开始,包括紧跟在CheckSum标记域的分界符每个字符的2进制和同CheckSum进行比较得到。

加密 Encryption

敏感数据在公众网络上的传输建议采用数据加密技术来掩饰应用消息。
加密算法由连接双方共同协商。
一个消息的任何一个域可以被加密并放在SecureData域中。然而,一些显示的标志域必须采用明文进行传输。为确保完整性,明文域可以在SecureData域中重复。
当使用加密时,建议但不是必须,所有的消息体都进行加密。如果一个消息中的重复组数据中的部分数据要加密,这个重复组必须全部进行加密。
预先协商好的加密算法在Logon消息中进行声明。

自定义域

  • FIX为给用户提供最大的灵活性,FIX协议允许用户自定义域。这些域在认同的参与者之间实现、应用,并且应注意避免冲突。
  • Tag数在5000 到9999保留用于用户自定义域。这些tag值用于企业联盟的信息交换。可以通过FIX网站进行注册。
  • 10000以上保留用于单一企业内部使用。不用注册。

消息类型

初始化过程之后,正常的消息交换将开始。所有有效的消息格式的细节将在“Adminitrative Message ”管理消息和“Application Messages”应用消息部分介绍。

1. 管理信息

它是为了信息交换过程更加顺畅一致而使用的控制,包括:登录、心跳、检验请求、重新发送请求、拒绝(交换过程)顺序重设及注销等。

2. 应用消息

也就是交易的数据,它包括:

  • 公告 宣布已完成的交易信息。
  • 重要提示 告知由经纪人买卖的证券是由私人股份有限公司所有,还是由代理持有,以及持有量。
  • 消息 是经纪人和机构之间传送的一般自由格式信息,带有识别信息紧急性和商号主题词分类标志。
  • 电子邮件 其格式和用途与消息信息相同,但更倾向于双方非公开的用途。
  • 报价请求 有些市场,要求经纪人在每次订单前提出报价。
  • 报价与多宗报价 回应报价请求的信息,并用于发表主动的报价。
  • 请求对多宗报价的确认 使用报价回应水平标记,有选择地支持对报价的确认。
  • 报价撤销 报价发起人用于撤销报价。
  • 报价状况请求 机构用来生成执行报告。
  • 报价确认 针对报价、多宗报价、报价撤销和报价请求,作出回应。
  • 行情数据请求 通过此请求得到所指定的证券和外汇交易报价的行情数据。
  • 行情数据—快照/完全刷新 该信息用于发送双方的订单登记簿、报价清单、交易清单、指数值、开盘价、收盘价、成交单价、最高价、最低价和变动加权平均价等。
  • 行情数据—添加刷新 用于添加刷新请求。
  • 行情数据请求拒绝 用于经纪人因交易或技术上的原因不承兑行情数据请求的情况。
  • 证券定义请求 用于某一指定证券与第二方交易。
  • 证券定义 接受或拒绝证券定义信息中请求的证券,发回证券及类型清单。
  • 证券状况请求 用于提出有关证券状况的请求。
  • 证券状况 提供有关证券状况改变的报告。
  • 交易盘状况请求 请求有关市面状况的信息。
  • 交易盘状况 提供有关市场状况的信息。
  • 新订单—单一 机构向经纪人提供有关证券或外汇的订单。
  • 执行报告 确认收到订单或订单改变信息,传递订单状况或订单成交信息,报告交易的费用。
  • 未知交易 通知交易方,收到的订单已被执行。
  • 订单撤销/替换请求 改变订单的参数。
  • 订单撤销拒绝 是经纪人在不能承兑所收到的撤销请求信息时发出的信息。
  • 订单状况请求 机构要求经纪人生成并发挥有关订单状况的信息。
  • 划拨 指定如何将一个订单或一组订单细分为一个或多个账户。
  • 划拨确认 确认收到机构发送的划拨信息及状态。
  • 结算指令 经纪人或机构交易结算的指令。
  • 出价请求 在“非公开”市场与“公开”市场,因市场规则不同,该信息的用法也不同
  • 出价回应 因两个市场规则不同,有不同的用法。
  • 新订单—清单 因两种市场规则的不同而不同。
  • 敲定价 交换本金交易的敲定价。
  • 状况清单 卖方以主动方式发送回应状况清单请求信息。
  • 清单执行 机构用于指示经纪人开始执行已被提交的证券订单信息。
  • 清单撤销执请求 用于机构希望在执行交易盘之前或之中,撤销已被提交的证券订单消息。
  • 状况清单请求 用于机构指示经纪人生成有关某一状况清单的信息。
  • 清单订单信息的分解 使用与其它FIX信息相同的方法,支持程序交易中的信息分解。
  • 交易信息拒绝 拒绝因遵循了交易盘规则而不能以其它方式进行拒绝的应用层面的信息。

消息格式

数据类型

整数int,浮点数float,单个字符char,布尔Boolean,字符串String,数据data

每条FIX信息都是由一系列带有〈标记〉=〈值〉的域组成。每个标记代表不同的含义,可以是信息的类型,目标商务名称,证券买入价等。FIX协议规定了0~5000的标记含义(fix信息字典),5000以上可由使用者自己定义,以适用特定的应用。

参考

https://www.fix-events.com/Archives/asianfix2008/cn/pdf/AlanDean_Chi.pdf

https://l297.oschina.io/15034517662312.html

https://juejin.im/post/5bf7c4ae51882528c4467649

https://www.huiyep.com/knowledge/155062.html

https://github.com/quickfix/quickfix/blob/master/examples/executor/python/executor.py

我的微信公众号:pyquant

FIX协议介绍与QuickFIX使用入门(上)_第2张图片

你可能感兴趣的:(FIX,其它)