泉州网站建设网站,网站建设哪家g,微网站开发教程,阳江网签由于作者还未在真实项目中实践#xff0c;以下知识均限于学习#xff0c;有些知识来源网络#xff0c;不保证绝对准确。 一、FIX是什么#xff1f;
是一个适用于实时证券和金融电子交易开发、不受单一实体控制的开放的数据通信标准#xff0c;此协议能够被调整适用于任何… 由于作者还未在真实项目中实践以下知识均限于学习有些知识来源网络不保证绝对准确。 一、FIX是什么
是一个适用于实时证券和金融电子交易开发、不受单一实体控制的开放的数据通信标准此协议能够被调整适用于任何一个企业的需求。
二、FIX的发展和地位
FIXFinancial Information eXchange Protocol金融信息交换协议是由国际FIX协会组织提供的一个开放式协议目的是推进国际贸易电子化进程把证券金融业务流程格式化成为一个可用计算机语言描述的功能流程在各种参与者之间包括投资经理、经纪人、买方、卖方创建实时的统一交换格式的通信协议。
优点是接入新的合作方, 时间大大缩短接入方式提明显便捷,相当于多国使用一个统一的语言交流无障碍。
缺点是据说速度慢
三、FIX基本流程
3.1 使用成员
Initiator 发起者建立通信连路通过发送初始Logon消息发起会话的参与方。
Acceptor 接收方 负责执行第一层次认证和经过传输Logon消息响应确认正式链接请求被接受
3.2 基本流程
FIX连接 由3部分组成logon登录message exchange消息传输logout注销。
logon logout注销 session会话
介绍一个FIX会话定义为一个在连接双方间的的带有连续序列号的有序消息双向传输流由一个或多个FIX Connection 组成。一个FIX会话可以有多次登录参与方能够多次连接和断开连接。
开始和结束参与方必须根据单个系统及时间区域需求公共协商会话的开始和结束。重新设置接收和发送序列号为1意味着一个新的FIX会话的开始。
过程每一个FIX参与方必须为FIX Session维护两个序列号接收序列号和发送序列号二者都在创建Session时初始化为1。每一个消息被赋予一个惟一的序列号值并在消息发送后递增。每一个收到的消息都有一个惟一的序列号接收序列号计数器在收到每一个消息后将会被递增。
3.3 使用建议
来自网络未实际项目实践
建议一个新的FIX会话在每24小时建立一次。维持24小时的连接后通过设置在Logon消息中的ResetSeqNumFlag建立一套新的序列号。重置seq, 可以由session的任何一方发起, 一般会提前协商好
四、具体协议
FIX协议的数据类型:整数int,浮点数float,单个字符char,布尔Boolean,字符串String,数据data 4.1 消息格式简介
FIX协议的格式存在着两种结构
TagValue 域结构, 一维的文本协议一般大家都使用此结构FIXML 结构
4.2 TagValue
基本格式为:[标准头][信息正文域][标准尾]每条信息都是由一系列TagValue对组成的。
除了一些特殊规定外信息中的域可按照任意顺序排列。所有域在都以定界符0x01(SOH表示终止。
列举常见的tag仅供了解tag功能具体参考官方文档 4.3 结构规定
这些规定构成了消息的基石 一条FIX消息的组成, 必须是headerbodytail, 顺序不能变即开始部分应是消息头随后是正文最后是消息尾;header的前三个tag一定是8FIX.X.XSOH9xxSOH35xxSOH即起始串(Tag 8)、消息体长度(Tag 9)、消息类型(Tag 35) tailer消息尾的最后一个tag一定是10xxxSOH重复域组的顺序, 一定是先有NoXXXrepeated fields域出现的顺序应遵循该重复组在消息或组件中定义时的次序;在一条消息中除重复组域外任何其他域不能重复出现。图中信息解释
域块多个域的集合
重复组由多个重复组块组成
组块表示重复组中的重复部分由域块组成
组件多个域的集合它们所代表的含义间有关联。 4.4 标准头结构了解
只列举必须字段 Tag 字段名称 字段说明 必送 注释 8 BeginString 版本号 Y 固定为FIX.4.2(不能加密必须是消息的第1个字段) 9 BodyLength 消息体长度 Y (不能加密必须是消息的第2个字段)不包括8\9\10字段长度 35 MsgType 消息类型 Y (不能加密必须是消息的第3个字段) 49 SenderCompID 发送者ID Y (不能加密) 56 TargetCompID 接收者ID Y (不能加密) 34 MsgSeqNum 会话序号 Y 开市期间不允许重置除非当天第一次登录 52 SendingTime 发送时间 Y 使用UTC时间格式
4.5标准尾结构了解
只列举必须字段 Tag 字段名称 字段说明 必送 注释 10 CheckSum 校验位 Y 整包校验码收发检查
4.6 自定义域了解
FIX为给用户提供最大的灵活性FIX协议允许用户自定义域。这些域在认同的参与者之间实现、应用并且应注意避免冲突。
Tag数在5000 到9999保留用于用户自定义域。这些tag值用于企业联盟的信息交换。可以通过FIX网站进行注册。10000以上保留用于单一企业内部使用。不用注册。
4.7 FIXML及其它基于XML数据的传输了解
尽管FIX会话协议的标准头Standard Header标准尾部Standard Trailer和管理消息是基于“tagvalue”语法的但它能够支持传输FIXML及其它基于XML的数据。FIXML及其它XML数据被夹在FIX标准头与FIX标准尾部中间并通过标准头的XmlDataLen域指定其内容长度XmlData域包含其具体的数据。这样FIX引擎可以通过多年使用的可靠的实时地异步传输机制传送FIXML及其它XML数据。当MsgType域值为’n’时代表传输的数据为FIX未在MsgType中定义的XML数据。
4.8实例后续补充 五、保证数据可靠的机制
数据传输基本存在两个核心问题泄露和篡改。
笔者认为主流解决方案分别就是签名解决篡改和加密解决泄露下面看下FIX的做法。
5.1保证数据完整
通过BodyLength 和CheckSum 进行检查
BodyLength包体长度:在tag BodyLength后面所有的数据, 包括SOH,程序通过计算BodyLength域到CheckSum标记“10”分界符的字符数域BodyLength标示的消息长度进行比较来完成完整性效验。
ChekSum消息校验和:完整性检查通过计算从域“8***” 中“8”开始直到CheckSum前面的SOH,每个字符的2进制和同CheckSum进行比较得到。然后校验和被转换为模256的数字用于传送和比较。校验和在所有加密操作之后被计算。
比如如果消息的校验和为274则模256后为1825618 274。这个值将采用|10018|进行传输其中“10”是校验和域的标签。
char *GenerateCheckSum( char *buf, long bufLen ) {static char tmpBuf[ 4 ];long idx;unsigned int cks;for( idx 0L, cks 0; idx bufLen; cks (unsigned int)buf[ idx ] ); sprintf( tmpBuf, “%03d”, (unsigned int)( cks % 256 ) );return( tmpBuf );
}
5.2保证数据安全
为了保证信息安全除某些需要公开识别的域以明文传输外其他任何域都可以加密放置密文数据域 (SecureData)内加密方法双方协议而定。如果有些确实需要明文传输以便识别的tag, 可以再加密一份, 用于校对
当然这些被加密的域也可以同时保留明文的表示方式。 六、保证交互过程可靠的机制
和大多数网络传输的问题一样需要保证不重、不漏、时序性为此介绍一个重要概念
seq每条FIX消息都有一个惟一的序列号进行标识序列号在每个FIX Session开始时被初始化为1并在整个Session期间递增此序列号也是FIX实现可靠传输过程的基石。
6.1不丢包
seq
session的两端, 各自维护一个outgoing seq(每个新的msg, seq1)和一个incoming seq(用来监控是不是丢包了)。每条FIX消息都会有一个seq, 每个FIX Session建立的时候会将seq初始化为1, 后续消息会依次累加.
通过seq, 接收方就可以知道是不是有FIX MSG丢了, 一旦发现丢失, 可以及时做出补救措施连接管理与业务处理解耦
HeartBeat
监控连接状态, 检查是否有msg丢失. (发送Heartbeat的周期间隔由会话发起者使用Logon消息中HeartBtInt域设置好, 双方相同由会话发起方定义并由会话接收者通过Logon消息进行确认).
和大多数优秀的开源组件一样如redis在消息交互期间FIX程序周期性产生心跳消息该消息可以监控通信链路状态及识别接受序列号间隙。
Heartbeat心跳消息的时间间隔在每一个消息发送后复位即发送一个消息后在间隔给定的时间内无其它消息发送则发送一个Heartbeat心跳消息。
再强调一遍同一个HeartBtInt被会话双方——登录的发起者和登录的接受者共同使用。 6.2不重复 6.3时序性
客户端
还是通过seq按照seq的从小到大, 依次处理.
如果收到了5个消息中的1,2, 4, 5, 而丢掉了第3个msg, 那么处理方式有2种. 1、接收方生成这个ResendRequest, 要求发送方将3-5这3个消息全都 重新发送一遍. 2、接收方生成这个ResendRequest, 要求发送方将第3个消息重新发 送一遍
两种方式的利弊很明显就不分析了记住无论怎样客户端收到完整的消息后, 再依次处理。
服务端 重传请求的响应消息都包含值为‘Y’的PossDupFlag域。没有PossDupFlag域或PossDupFlag域为‘N’的消息应被看成初始传送消息。值为‘Y’的重传消息要重新计算其CheckSum值。复制消息中发生变化的域包括CheckSumOrigSendingTimeSendingTimeBodyLength和PossDupFlag加密相关域SecureDataLen和SecureData也必须被重新构造。 两种重传情况
1Possible Duplicates
收到接收方的ResendRequest, 或怀疑没发出(如进程重启时的msg), 设置PossDupFlagY, 使用原来的seq, 重新计算CheckSum将msg重新发送一次 2Possible Resend
订单很久没响应时, 会怀疑这个单没发出去, 就会考虑重新下一单. 设置msg的PossResendFlagY, 使用新的seq, 但是OrderId不变, 重新下单。接收方需要识别PossResendFlag, 并通过OrderId准备识别出这个Order是不是之前已经收到过, 并正确处理。
PossResend 和 PossDupFlag 区别就是前者使用了新序列号发送老的消息可以通过检查消息中的域来确定是否已经收到过该消息比如 order 的 ID 等后者是用老的序列号重发消息可以直接检查序列号来确定是否已经收到过该消息若已收到过了就丢弃该消息。
七、其它协议了解
FAST协议
为了解决FIX协议传输市场数据存在的冗余度高带宽需求大的问题芝加哥商品交易所CME在2003年向FPLFIX Protocol Ltd提交了一个解决方案FPL在2004年成立了市场数据优化工做组(MDOWG)2005年MDOWG开始根据一些POC(Prove of Concept)的结果进行协议标准制定并于2006年初完成了FAST(FIX Adapted for Streaming) V1.02006年12月完成了FAST V1.1。 FAST协议核心是一个压缩算法将按照FIX规范定义的数据通过压缩后能够在很大程度上下降发送、接收双方的带宽。 FAST协议的优势是高压缩比低资源消耗算法简单高效每秒百万级别的消息处理能力。
STEP协议
STEPSecurities trading exchange protocol证券交易数据交换协议是基于FIX4.4版本FIX协议制定出来的中国本地化FIX协议版本是中国国家金融行业标准已成为事实上的证券数据标准其语法简单定义灵活易扩展数据相对冗余。
Binary协议
Binary即二进制协议定义了各类报文的字段、编解码规则等。在深交所的Binary协议中全部的消息都有3部分组成消息头消息体和消息尾。消息头有8个字节包括整数MsgType和整数BodyLenMsgType表示消息的类型BodyLen表示消息体的长度消息体根据BodyLen大小进行读取消息尾是4个字节的 checksum。 八、推荐文档
官网应用层规范https://www.fixtrading.org/standards/
官网参数文档https://www.fixtrading.org/online-specification/global-components/
fast协议githttps://github.com/kuangtu/fixfast/blob/master/References/FAST%20Specification%201%20x%201.pdf
quickfix官方githttps://github.com/quickfix/quickfix
csdn阅读最多的fix文章https://blog.csdn.net/eryk86/article/details/96275929https://blog.csdn.net/eryk86/article/details/96275929
被抄袭较多实现了一个简单demohttps://juejin.cn/post/6844903720593915911#heading-25
