1、Version1.00 轻量级 STEP 会话层接口规范 2015-08-28I轻量级 STEP 会话层接口规范(LFIXT 会话协议)Version 1.00Lightweight Fix Session Layer Protocol本规范由上海证券交易所和深圳证券交易所联合发布2015-08-28Version1.00 轻量级 STEP 会话层接口规范 2015-08-28II文档说明文档名称 轻量级STEP会话层接口规范内容描述 描述了轻量级的STEP会话协议相关内容。修订历史日期 版本 修订说明2014-01-20 0.8 创建2014-3-26 1.00根据会员反馈意见进行修订:1.
2、 增加了REJECT消息 2.修正了一些文字错误 3. 将LFIXT协议细分为兼容模式和精简模式,并列明协议兼容性矩阵及典型应用场景;4. 为Logon消息增补了会话状态字段 5. 根据会员反馈意见增补了字段长度说明; 6.解释了什么叫做Garbled Message 7.根据正文的变更修订了附录2014-04-10 1.0011. 修正了tag 1408的说明文字,1.00中写的“STEPn.x.y”并不合乎当前 STEP协议的版本命名规则。 2. 修正4.2节中tag 49, tag 56的说明文字及ResetSeqNumFlag的tag。3.修正附录H中关于Reject消息检查的一个笔误
3、除此之外,本版本和1.00内容并无不同。2014-08-10 1.0021. 补充了一些字段的最大宽度说明2. 修正MessageEncoding的说明,令缺省值为GBK2014-10-20 1.001 1. 将版本名称从1.002重命名为1.0012015-08-28 1.00 1. 将版本名称从1.001重命名为1.00Version1.00 轻量级 STEP 会话层接口规范 2015-08-28III名词释义词汇缩写 含义STEPSecurities Trading Exchange Protocol证券交易数据交换协议。FIXFinancial Information Exchange
4、金融信息交换协议。Version1.00 轻量级 STEP 会话层接口规范 2015-08-28IV目录一、 范围 .1二、 会话机制 .22.1 术语和定义 .22.1.1 会话层重传 .22.1.2 应用层重传 .22.1.3 NxtIn 和 NxtOut .22.1.4 会话发起方和接受方 .22.1.5 消息序号 .32.1.6 心跳 .42.1.7 有序消息处理 .42.1.8 可能的消息重复传送 .42.1.9 可能的消息重新发送 .52.1.10 消息完整性 .52.1.11 混乱的消息(garbled message) .52.1.12 消息确认 .62.1.13 加密 .62
5、.2 会话管理 .62.2.1 建立会话 .62.2.1.1 建立连接 .62.2.1.2 身份认证 .62.2.1.3 消息同步 .72.2.2 消息交换 .72.2.3 注销会话 .72.3 恢复 .72.3.1 登录消息处理 .72.3.2 重传请求消息处理 .72.3.3 序号重设消息处理 .8三、 消息定义 .93.1 消息结构 .93.1.1 消息头 .93.1.2 消息尾 .93.2 管理消息 .103.2.1 Heartbeat 心跳消息(MsgType = 0) .113.2.2 Logon 登录消息(MsgType = A).123.2.3 TestRequest 测试请求
6、消息(MsgType = 1) .133.2.4 Resend 重发请求消息(MsgType = 2) .133.2.5 Reject 会话拒绝消息(MsgType=3) .143.2.6 SeqReset 序号重设消息(MsgType = 4).163.2.7 Logout 注销消息(MsgType = 5) .16四、 数据字典 .184.1 数据类型 .18Version1.00 轻量级 STEP 会话层接口规范 2015-08-28V4.2 会话层域定义 .19附 录 A.21(登录场景) .21正常登录场景一 .21正常登录场景二 .21正常登录场景三 .22异常登录场景一 .24异
7、常登录场景二 .24附 录 B .26(注销场景) .26正常注销场景 .26附 录 C.27(处理重传请求场景) .27处理重传请求场景一 .27处理重传请求场景二 .28附 录 D.30(处理心跳和测试请求) .30处理心跳和测试请求 .30附 录 E .31(处理会话拒绝) .31处理会话拒绝 .31附 录 F.32(计算校验和) .32计算校验和 .32附 录 G.33(状态转换参考图) .33LFIXT 会话协议状态转换参考 图 .33附 录 H.34(实现参考) .34LFIXT 会话协议实现参考 .341. Logon 消息 .342. Heartbeat 消息 .353. Te
8、stRequest 消息 .354. ResendRequest 消息 .355. SeqReset-Reset 消息 .366. SeqReset-GapFill 消息 .367. Reject 消息 .378. Logout 消息 .379. 应用消息 .37Version1.00 轻量级 STEP 会话层接口规范 2015-08-28第 1 页共 38 页轻量级 STEP 会话协议接口规范范围本标准对 STEP 会话层协议(即 FIX 会话层协议 FIXT 1.1 版本)进行了裁剪和改造,确立了一个基于 TCP 的轻量化 STEP 会话层协议(记 作:LFIXT 会话层协议),同时 LF
9、IXT标准仍然可以保持和标准 STEP/FIX 会话层协议的互操作性。本标准规定了 LFIXT 会话层协议使用的会话机制、消息格式、安全与加密、数据完整性、扩展方式、消息定义、数据字典等内容。如无特别说明,本标准中提及的接收方、发送方等通信参与方均特指遵循 LFIXT会话层协议而实现的应用程序或模块。由于遵循本 协议开发的程序或模块将可以同标准 FIX 引擎进行正常通信,因此若通信的一方是标准的 FIX 引擎,则除本文特别制订的少数额外约束外,其实现不受本文档 约束。Version1.00 轻量级 STEP 会话层接口规范 2015-08-28第 2 页共 38 页会话机制2.1 术语和定义2
10、.1.1 会话层 重传会话层重传是标准FIX会话层协议所规定的一种重传机制,用来确保有序、无失地传输每一条会话层消息。在 标准FIX会话层协议中,会话层重传由消息接收方在识别出消息序号缺口之际主动发起,采取的方式是发送一条消息重传请求给到对方。LFIXT会话协议在事实上取消了标准FIX会话层协议的会话层重传,只对外仍然表现为标准的FIX会话层,且可以和对端的标准FIX 会 话层实现进行互操作。由于单个LFIXT会话使用 单个TCP连接作为底层通信机制,因此在单个TCP连接内部,每一条消息将被有序、无失地传输。属于同一会话的、前后相继的若干次TCP连接之间,将可能存在会话层消息丢失,但收到的会话
11、层消息将仍然具有有序接收的性质。由于在LFIXT下会话层可能存在消息丢失,因此丢失的业务消息将只能通过应用层重传予以恢复。2.1.2 应用层 重传由于LFIXT会话协议的会话层恢复机制仅仅是为了与标准FIX会话协议兼容,不能作为真正的消息恢复机制使用。因此,必须通过应用 层商定的重传机制予以恢复。 应用层重传的具体机制不属于本文档规定的范畴,请参见具体的应用层数据接口规范。2.1.3 NxtIn 和 NxtOut会话双方收发的每条消息都带有一个消息序号。参与通信的每一端都需要维护一对序号(NxtIn, NxtOut),NxtIn表示下一个期望的入向消息序号,NxtOut表示下一条出向消息将被赋
12、予的序号。2.1.4 会话发 起方和接受方会话的建立需要一个发起方,需要一个接受方。发起方是先发出Logon 消息并希望对方响应以一个Logon消息的一方,接受方 则是等待 发起方首先发出Logon消息并响应以Logon 消息的一方。会话的发起方和接受方在会话建立后都可以双向地进行消息的发送和接收。不要将会话发起方(initiator )、会话接受方(acceptor)同某条特定消息的发送方(sender)和接收方(receiver )混为一谈。类似于会话发起方和会话接受方,也定义有注销发起方和注销接受方、会话重置发起方和会话重置接受方的概念。Version1.00 轻量级 STEP 会话层接
13、口规范 2015-08-28第 3 页共 38 页标准FIX协议原则上适用于各种不同的传输层协议(如UDP),因此不可能根据TCP socket等特定的传输层信息来区分哪些报文隶属于同一个FIX会话,而且由于FIX中并不为每个FIX 会话定义有所谓“会话号”标签,且不是全部报文都具有username一类的标签,因此区分FIX会话的唯一标识符只能是SenderCompID和TargetCompID 的组合。标准FIX协议中,单个FIX引擎不能同时维护相同SenderCompID+TargetCompID的两个会话。 标准所推荐的做法是:在已存在一个合法会话时,若一方试图以同样的SenderCom
14、pID + TargetCompID发起新的会话,对 方将不发送任何Logout消息就直接终止新发起的会话,原先已存在的会话不应受到影响。标准FIX协议并未明确不同的FIX引擎是否允许同时保有同样标识的会话。一般而言,同一台服务器上的同标识 会话较易进行查重, 针对 不同服务器建立的同标识会话则较难实现查重,但也非无法做到。LFIXT协议规定:在处理入向登录报文时,应利用SenderCompID和TargetCompID进行会话查重,之前已存在的同 标识会话一定不受影响,但较晚收到的同标识会话请求可能被接受,但也可能被拒绝 ,协议不作限定。若 请求被拒 绝,则拒绝方式将遵循标准FIX协议的约定
15、,不回送Logout 消息,直接断开 TCP连接。会话发起方应当对这种情形做好准备。LFIXT协议只允许单个会话同时通过单个TCP连接进行全双工通信,因此在通过登录报文信息确定是否允许继续通信后,可以直接利用socket来区分报文所属会话,但对于从同一socket上收到的后 续报文仍应检查其SenderCompID和TargetCompID 是否和登录时一致。2.1.5 消息序号所有的消息都由一个唯一的会话层消息序号(即消息头中的 MsgSeqNum 字段)进行标识。消息序号在会话开始 时一般被初始化为 1,并在整个会话过程中连续递增 1,直到该会话过程全部结束。通 过监视消息序号的连续性,通
16、信双方可以识别消息缺口并做出反应,并可在同一会话的前后多个连接间进行同步 2。每次会话都会创建一套独立的入向及出向的序号序列,参与连接的任何一方都维护一套用于出向消息的序号序列(NxtOut),同时也维护另一套独立的入向消息的序号序1. 这个说法是针对通常情况而言的。在下述情况下,接收方收到的消息的 MsgSeqNum也可能出现倒流:1)收到的消息是 SeqReset-Reset消息且 PossDupFlag=Y,此时 MsgSeqNum应忽略,即使出现倒流也不是错误;2) 除此以外,所收到消息的 PossDupFlag是 Y,且此类消息确实允许出现 PossDupFlag=Y,表示这是会话层重传;3) 通过 LOGON消息进行会话序号重置时,收到的消息其 MsgSeqNum一定是 1,因此也可能出现倒流。2. LFIXT会话协议在事实上取消了标准 FIX会话层协议的会话层重传,这里的同步只是为了兼容标准 Fix会话机制,并不进行真实的消息同步。Version1.00 轻量级 STEP 会话层接口规范 2015-08-28第 4 页共 38 页列(Nxt
Copyright © 2018-2021 Wenke99.com All rights reserved
工信部备案号:浙ICP备20026746号-2
公安局备案号:浙公网安备33038302330469号
本站为C2C交文档易平台,即用户上传的文档直接卖给下载用户,本站只是网络服务中间平台,所有原创文档下载所得归上传人所有,若您发现上传作品侵犯了您的权利,请立刻联系网站客服并提供证据,平台将在3个工作日内予以改正。