fix1金融交易协议总结Word格式文档下载.docx
《fix1金融交易协议总结Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《fix1金融交易协议总结Word格式文档下载.docx（9页珍藏版）》请在冰点文库上搜索。
版本与版本的不同：
TI（thetransportindependence
）特性，即传输无关框架。
TI将FIX会话层从应用层协议中分离出来。
在TI框架下，应用层协议消息能够通过任意适合的传输技术进行传送，在那个地址，FIX会话层协议是FIX应用层消息的可选传输传输协议之一。
FIX协议特点及其优势
FIX协议由于其开放的体系，具有如下四个要紧特点：
利用简单，各类应用系统能够依据FIX协议规那么，编写自身的应用程序，应用于任何希望自动连接的交易两边，能支持各类商务功能。
规那么开放透明，具有不断扩充的能力。
为了把最大的灵活性给予用户，FIX鼓舞用户自概念域。
这些域应在已达到有关共识的交易各方范围内利用，并应警惕利用，以幸免在各方实施该协议之初的时候容易引发的冲突。
FIX由一个非盈利的FIX组织治理保护，发布FIX协议的标准化格式，在鼓舞卖主加入该标准的同时，FIX始终维持中立。
不受载体的限制，它可通过租用数据线路、数据转接介质或在互联网上利用，
平安机制方面，FIX不提供特定的平安机制，它只是一个信息互换平台。
但它支持任何两边许诺的加密体系。
由于有上述的四个特点，实施FIX所带来的优势要紧表此刻：
降低整合各类内部操作程序的本钱及复杂性
降低与新交易伙伴连接的本钱及复杂性
由于规模经济效应或挖掘共享基础设施的潜能，实现自动化处置所需的投入（如软件和硬件）因此下降
因人工重输信息或利用转换引擎所造成的潜在错误减少，市场参与者之间的通信质量因此取得了提升
FIX协议结构
FIX协议的格式存在着两种结构:
tag=value结构和FIXML结构。
目前采纳的都是第一种方式来完成数据互换。
本报告要紧讲述这种格式的消息。
其中FIXML可读性更强，但占用更多的带宽资源。
FIX消息模式
FIX消息格式：
每一个FIX消息均由消息头、消息体和消息尾组成。
每一个消息均由一系列的<
tag>
=<
value>
字段组成，字段间用分隔符<
SOH>
（0x01）分割。
消息头开始顺序有如下三个字段：
BeginString（tag#8）followedbyBodyLength（tag#9）followedbyMsgType（tag#35）.尔后还包括有其他字段；
消息尾确实是一个CheckSum（tag#10）；
所有FIX消息都是以“8=<
”开始，以“10=nnn<
“终止。
具体的消息格式在《中信证券FIXGW接入说明》中有说明。
2协议工作原理
2.1通信模型及大体概念
通信模型
Initiator
：
发起者，成立通信连路，通过发送初始Logon消息发起会话的参与方。
Acceptor
接收方FIX会话的接收方。
负责执行第一层次的认证和通过传输Logon消息的确认正式声明连接请求被同意。
原那么：
先发起者为Initiator
，同意者为Acceptor
。
标准模式以网关为Acceptor，客户端为Initiator做为经常使用模式。
Fixconnection
FIX连接由3部份组成：
logon登录，messageexchange消息传输，和logout注销。
Fixsession
FIX会话由一个或多个FIXConnectionFIX连接组成。
一个FIX会话能够有多次登录。
SequenceNum
所有的FIX消息都由一个唯一的序列号进行标示。
序列号在每一个FIX会话开始时被初始化为1，并在整个会话期间递增。
监控序列号能够使会话参与者识别和处置丢失的消息，当在一个FIX会话中从头连接时能够快速进行应用程序同步。
每一个会话将成立一组互不依托的同意和发送序列。
会话参与者将保护一个给予发送消息的序列和一个监控同意消息的消息块间隙序列号。
Heartbeats
在消息交互期间，FIX应用程序将周期性产生Heartbeat心跳消息。
该心跳消息能够监控通信链路状态及识别接收序列号间隙。
发送Heartbeat的周期距离由会话发起者利用在Logon消息中HeartBtInt域进行概念。
Heartbeat心跳消息的时刻距离应当在每一个消息发送后复位，即发送一个消息后，在距离给定的时刻内无其它消息发送那么发送一个Heartbeat心跳消息。
HeartBtInt的值应当被会话两边认同，由会话发起方概念并由会话接收者通过Logon消息进行确认。
同一个HeartBtInt被会话两边——登录的发起者和登录的同意者一起利用。
Dataintegrity和Checksum
消息数据内容的完整性能够参用两种方式来验证：
消息长度和效验码检查。
程序通过计算BodyLength域到（并包括）在CheckSum标记（“10=”）后的分界符的字符数与在BodyLength中标示的消息长度进行比较来完成完整性效验。
CheckSum
ChekSum完整性检查，通过计算从域“8=”中“8”开始，包括紧跟在CheckSum标记域的分界符<
每一个字符的2进制和同CheckSum进行比较取得。
一个FIX消息校验和通过计算到ChechSum域（但不包括）的消息的每一个字节和取得。
然后，校验和被转换为模256的数字用于传送和比较。
校验和在所有加密操作以后被计算。
产生校验和的代码示列如下：
char*GenerateCheckSum（char*buf,longbufLen）
{
staticchartmpBuf[4];
longidx;
unsignedintcks;
for（idx=0L,cks=0;
idx<
bufLen;
cks+=（unsignedint）buf[idx++]）;
sprintf（tmpBuf,“%03d”,（unsignedint）（cks%256））;
return（tmpBuf）;
}
MessageAck
FIX协议不支持单个消息的确认。
采纳的是监控消息时隙的方式来进行消息恢复和验证。
一般的数据传送（无单个消息确认）通过消息序列间隙进行错误识别。
每一个消息由一个唯一的序列号进行标示。
接收端应用程序负责监控接收消息序列号以识别消息间隙并产生重传请求。
每一个FIX参与方必需为FIX会话保护两个序列号，一个是接收序列号，一个是发送序列号，二者都在成立FIX会话开始时初始化为1。
每一个消息被给予一个唯一的序列号值，并在消息发送后递增。
另外，每一个收到的消息都有一个唯一的序列号，接收序列号计数器在收到每一个消息后将会被递增。
当接收序列号与所希望取得的的正确序列号没必要配时，必需采取纠错处置。
Encryption
加密算法由连接两边一起协商。
一个消息的任何一个域能够被加密并放在SecureData域中。
但是，一些显示的标志域必需采纳明文进行传输。
为确保完整性，明文域能够在SecureData域中重复。
当利用加密时，建议但不是必需，所有的消息体都进行加密。
若是一个消息中的重复组数据中的部份数据要加密，那个重复组必需全数进行加密。
预先协商好的加密算法在Logon消息中进行声明。
Userdefinitionfield
FIX为给用户提供最大的灵活性，FIX协议许诺用户自概念域。
这些域在认同的参与者之间实现、应用，而且应注意幸免冲突。
Tag数在5000到9999保留用于用户自概念域。
这些tag值用于企业联盟的信息互换。
能够通过FIX网站进行注册。
10000以上保留用于单一企业内部利用。
不用注册。
2.2会话层协议
Logon登岸
成立一个FIX连接，别离包括3个操作：
创建通信层链路
接收者认证/同意发起者
消息同步（初始化）。
连接流程如下：
会话发起者同会话接收者成立通信链路，即TCP连接。
发起者发送一个Logon消息。
接收者检查Logon消息，认证发起者身份。
Logon消息包括支持之前两边协商好的认证方式所必需的数据。
若是发起者被成功认证，接收者用一个Logon消息进行响应。
若是认证失败，会话接收者将关闭链接，之前能够选择发送一个Logout消息以提示认证失败的缘故。
那个Logout消息不是必需发送的。
在发起者认证通过以后，接收者当即响应一个Logon确认消息。
依据会话利用的加密方式，那个Logon消息能够，也能够不报还一样的会话密钥。
发起者方将把接收方返回的Logon确认消息视为一个FIX会话成立的标志。
若是会话接收方选择单边会话加密密钥，会话的发起方必需发送一个Logon消息到对方以确认密钥改变请求。
如此，能让会话接收者明白发起者何时开始利用新的会话密钥。
发起方和接收方必需在发送任何查询或新消息之前通过询问MsgSeqNum域来同步其消息。
发起方能通过比较确认Logon消息的MsgSeqNum及下一个期望值来侦测消息的间隙。
Messsageexchange消息互换
初始化进程完成以后，将会进行正常的数据信息互换。
要紧包括治理消息和应用消息的传送。
Logout注销
正常的消息互换的终止将通过互换Logout消息来完成。
一样设计上会发送一个TestRequest消息强制请求从对方获取Heartbeat。
如此能够帮忙判定没有序列间隙。
在实际的会话关闭前，Logout的发起者应等待对方响应一个Logout确认消息。
这种方式给接收者在需要时一个执行任何间隙填充错作的机遇。
一旦ResendRequest消息被接收，接收者应发起Logout操作，而且接收者在适当的时刻表内没有响应，会话能够终止。
重传请求消息
下面四项待补充：
重传请求消息
测试请求消息
Reject消息
2.3应用层协议（待补充）
最重要的：
委托，查询，撤单，执行回报
3国内现有应用方案
金证：
ft_market/
将Fix协议的请求通过C/C++或XML方式转化成业务系统对应协议，同时转发还处置结果回报。
使得在业务系统与FIX接入方系统之间通过FIX协议进行互通连接。
国信：
GsApiFPL成员
根网科技：
n1/child.php?
id=46
恒生：
深圳证券通信公司：
Bloomberg、恒生、金证、根网、上期技术
4如何开发FIX程序
开发需求
短时间需求：
实现协议的客户端接入。
快速准确的协议说明及翻译。
与恒生柜台高速有效地通信。
实现路由功能，作为客户端和效劳端的适配器，实现星型连接。
实现大体的股票交易查询等功能点。
壮大的监控功能。
具有平安性保障。
开发方式
一样情形下，FIX开发中涉及到两方面，一个是会话层和应用层。
应用层即业务逻辑相关的层面，在把握好业务逻辑后，相对固定简单。
但是关于会话层的实现，涉及太多的方面，因此推荐采纳现有的FIX引擎来开发。
列出了全世界很多公司的183种不同FIXengines，固然，还包括一些没有记录上去的FIXengine。
国内现有的开发要紧采纳开源而且跨语种的QuickFIX引擎。
QuickFIX能够灵活的运用在C++、C#、Java、Python、Ruby等编程语言当中。
该引擎是目前应用较为普遍的FIX协议应用程序，但关于QuickFIX的文档还不是很多，有关它的技术资料能够登岸e查看。
测试方式（待补充）
会话层测试方式
应用层测试方式
参考文献
《X》
《FIX-4.2_VOL-X》
《标准化和FIX协议：
成立标准的市场源头》
《中信证券FIX网关接入说明》
《金融数据互换国际标准在证券》
金证《FIX网关解决方案.ppt》
《》
升级会员 