搜索结果: JR/T 0182-2020, JR/T0182-2020, JRT 0182-2020, JRT0182-2020
| 标准编号 | JR/T 0182-2020 (JR/T0182-2020) | | 中文名称 | 轻量级实时STEP消息传输协议 | | 英文名称 | Light weight real-time STEP message transfer protocol | | 行业 | 金融行业标准 (推荐) | | 中标分类 | A11 | | 国际标准分类 | | | 字数估计 | 33,312 | | 发布日期 | 2020-02-26 | | 实施日期 | 2020-02-26 | | 标准依据 | 中国证券监督管理委员会公告(2020)15号 | | 发布机构 | 中国人民银行 | JR/T 0182-2020
Light weight real-time STEP message transfer protocol
ICS 03.060
A11
JR
中 华 人 民 共 和 国 金 融 行 业 标 准
轻量级实时 STEP 消息传输协议
2020-02-26 发布
2020-02-26 实施
中国证券监督管理委员会 发 布
目 次
前言...II
引言...III
1 范围...1
2 规范性引用文件...1
3 术语和定义...1
4 会话机制...1
4.1 关键概念的重要说明...1
4.2 会话管理...5
4.3 恢复...6
5 消息规范...6
5.1 消息结构...7
5.2 管理消息...8
6 数据字典...14
6.1 数据类型...14
6.2 会话层域规范...15
附录 A （规范性附录）计算校验和...17
附录 B （规范性附录）处理心跳和测试请求...18
附录 C （规范性附录）登录场景...19
C.1 正常登录场景一...19
C.2 正常登录场景二...20
C.3 正常登录场景三...20
C.4 异常登录场景一...22
C.5 异常登录场景二...22
附录 D （规范性附录）处理会话拒绝...24
附录 E （规范性附录）处理重传请求场景...25
E.1 处理重传请求场景一...25
E.2 处理重传请求场景二...26
附录 F （规范性附录）注销场景...27
前 言
本标准依据GB/T 1.1-2009给出的规则起草。
本标准由全国金融标准化技术委员会证券分技术委员会（SAC/TC180/SC4）提出。
本标准由全国金融标准化技术委员会（SAC/TC180）归口。
本标准起草单位：中国证券监督管理委员会信息中心、上海证券交易所、深圳证券交易所、中证信
息技术服务有限责任公司。
本标准主要起草人：姚前、刘铁斌、周云晖、杜娟、朱立、王鹏飞、李向东。
引 言
协议即金融信息交换协议，是用于全球金融市场机构和参与者间的电子金融信息交互的协议，以下简称FIX协议。
1 范围
本标准规定了轻量级实时STEP消息传输协议
使用的会话机制、消息格式、安全与加密、数据完整性、扩展方式、消息格式
规范、数据字典等内容。
本标准适用于支持证券交易所与市场参与者和相关金融机构间的业务数据交换。本标准也可被推广
用于支持证券期货行业各机构系统间的会话连接。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文
件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
3 术语和定义
下列术语和定义适用于本文件。
3.1
证券交易数据交换协议 securities trading exchange protocol;STEP
证券交易所交易系统与市场参与者系统之间进行证券交易数据交换的行业信息标准。
3.2
金融信息交换协议 financial information exchange;FIX
进行证券交易信息电子交换的国际信息标准。
3.3
FIX会话层协议 fix session layer protocol;FIXT
独立于通信协议（如TCP、UDP等）和通信介质（如光缆、卫星等）的电子数据传输协议，FIX协议
的重要子协议。
4 会话机制
4.1 关键概念的重要说明
4.1.1 会话层重传
4.1.1.1 本标准给出了市场参与者内部系统通过开放接口与证券交易所间的会话层连接标准。本标准
是 FIX 标准化组织的 FIXT 1.1 标准的精简版，且消息标签的使用遵循 FIX 5.0 SP2 的规定。由于
JR/T 0022-2014 证券交易数据交换协议只是 FIX 协议的本地化版本，为凸显标准的直接来源，以下简
称本标准为“LFIXT”。
4.1.1.2 如无特别说明，本标准中提及的接收方、发送方等通信参与方均特指遵循本标准而实现的应
用程序或模块，以下简称为“LFIXT 参与方”。基于 FIXT 开发的程序或模块（以下简称为“FIXT 参与
方”），若要和 LFIXT 参与方进行通信，也需遵循本标准的约束。
4.1.1.3 会话层重传是会话层协议所规定的一种重传机制，用来确保有序、无失地传输每一条会话层
消息。在 FIXT 会话层协议中，会话层重传由消息接收方在识别出消息序号缺口之际主动发起，采取的
方式是给对方发送一条消息重传请求。本标准在事实上取消了 FIXT 会话层协议的会话层重传，只对外
仍然表现为标准的 FIXT 会话层，且可以和对端的 FIXT 参与方进行互操作。由于单个 LFIXT 会话使用单
个 TCP 连接作为底层通信机制，因此在单个 TCP 连接内部，每一条消息将被有序、无失地传输。属于同
一会话的、前后相继的若干次 TCP 连接之间，虽然可能存在会话层消息丢失，但收到的会话层消息将仍
然具有有序接收的性质。由于在 LFIXT 标准下会话层可能存在消息丢失，因此丢失的业务消息将只能通
过应用层重传予以恢复。
4.1.1.4 和 FIXT 协议一样，LFIXT 协议本身并不限定所用的标准端口号。作为基于 TCP 的会话层协议，
LFIXT 使用的端口号建议在区间[1024,49151]内，具体取值由通信双方事先另行约定。
4.1.2 应用层重传
由于本标准的会话层恢复机制仅仅是为了与FIXT会话协议兼容，不能作为真正的消息恢复机制使
用。因此，应通过应用层商定的重传机制予以恢复。应用层重传的具体机制不属于本标准规定的范畴。
4.1.3 NxtIn 和 NxtOut
会话双方收发的每条消息都带有一个消息序号。参与通信的每一端都需要维护一对序号（NxtIn，
NxtOut），NxtIn表示下一个期望的入向消息序号，NxtOut表示下一条出向消息将被赋予的序号。
4.1.4 会话发起方和接受方
4.1.4.1 会话的建立需要一个发起方，需要一个接受方。发起方是先发出 Logon 消息并希望对方响应
以一个 Logon 消息的一方，接受方则是等待发起方首先发出 Logon 消息并响应以 Logon 消息的一方。会
话的发起方和接受方在会话建立后都可以双向地进行消息的发送和接收。不要将会话发起方
（initiator）、会话接受方（acceptor）同某条特定消息的发送方（sender）和接收方（receiver）
混为一谈。
4.1.4.2 类似于会话发起方和会话接受方，也定义有注销发起方和注销接受方、会话重置发起方和会
话重置接受方的概念。
4.1.4.3 FIXT 协议适用于各种不同的传输层协议（如 UDP），因此不可能根据 TCP socket 等特定的
传输层信息来区分哪些报文隶属于同一个 FIXT 会话，而且由于 FIXT 中并不为每个 FIXT 会话定义有所
谓“会话号”标签，且不是全部报文都具有 username 一类的标签，因此区分 FIXT 会话的唯一标识符是
和字段的组合。LFIXT 标准作为 FIXT 标准的精简版，也遵循此要求。
4.1.4.4 FIXT 协议中，单个 FIXT 参与方不能同时保有具有相同的两个
会 话 。 在 FIXT 中 推 荐 的 做 法 是 ： 在 已 存 在 一 个 合 法 会 话 时 ，
若 一 方 试 图 以 同 样 的发起新的会话，对方将不发送任何 Logout 消息就直接终止新发起的会话，
原先已存在的会话不应受到影响。另一方面，FIXT 协议并未明确不同的 FIXT 参与方是否允许同时保有
同样标识的会话。一般而言，同一台服务器上的同标识会话较易进行查重，针对不同服务器建立的同标
识会话则较难实现查重，但也非无法做到。在处理入向登录报文时，应利用和 进行会话查重，之前已存在的
同标识会话一定不受影响，但较晚收到的同标识会话请求
可能被接受，但也可能被拒绝，FIXT 协议不作限定。若请求被拒绝，则拒绝方式将遵循 FIXT 协议的约
定，不回送 Logout 消息，直接断开 TCP 连接。会话发起方应当对这种情形做好准备。LFIXT 标准作为
FIXT 标准的精简版，也遵循此要求。
4.1.4.5 本标准只允许单个会话同时通过单个 TCP 连接进行全双工通信，因此在通过登录报文信息确
定是否允许继续通信后，可以直接利用 socket 来区分报文所属会话，但对于从同一 socket 上收到的后
续报文仍应检查其和 是否和登录时一致。
4.1.5 消息序号
所有的消息都由一个唯一的会话层消息序号(即消息头中的字段)进行标识。消息序号在
会话开始时在大多数情况下被初始化为1，并在整个会话过程中连续递增，直到该会话过程全部结束。
通过监视消息序号的连续性，通信双方可以识别消息缺口并做出反应，并可在同一会话的前后多个连接
间进行同步。
上述的“连续递增”是针对通常情况而言。在下述情况下，接收方收到的消息的也可能
出现倒流，但此时的倒流并非异常，而是被称为“正常倒流”：
a) 收到的消息是消息且，此时应忽略，即使出现倒流
也不是错误；
b) 收到消息的是 Y，且此类消息确实允许出现，表示这是会话层重
传；
c) 通过消息进行会话序号重置时，收到的消息其一定是 1，因此也可能出现倒
流。
每次会话都会创建一套独立的入向及出向的序号序列，参与连接的任何一方都维护一套用于出向消
息的序号序列，同时也维护另一套独立的入向消息的序号序列，用以监视接收的消息
序号，以保证消息缺口的发现和处理。
会话建立后，当LFIXT协议实现者接收到的消息序号不等于预期接收的消息序号(NxtIn)时，需要考
虑进行修正处理。这里有几种情况：
a) 如果入向消息序号且不属于正常倒流，表明发生了严重的错误，应立即结束会话，并
开始进行人工干预；
b) 如果入向消息序号且属于正常倒流，则不属于错误，应进行正常处理；
c) 如果入向消息序号那么表明有消息被遗漏。因为 LFIXT 使用 TCP 为传输协议，出现这
种情况说明发生了严重异常错误，应立刻终止当前会话。
4.1.6 心跳
在消息交换的空闲期间，连接双方将以规定的时间间隔产生心跳消息。通过心跳消息可以监控通讯
连接的状态并识别出入向消息序号的缺口。
心跳间隔时间由会话发起人通过登录消息的字段确定。在传送了任何消息(而不仅仅是
心跳消息)之后，都应立即重置心跳间隔计时器。心跳间隔时间应该得到连接双方的确认，由会话发起
人给出，并得到会话接受方的确认。
连接双方应使用相同的心跳间隔时间。每个心跳消息都将占用一个消息序号。
4.1.7 有序消息处理
本标准采用TCP连接作为底层通信机制。在会话建立后，在同一个TCP连接的延续期间，接收方在发
现入向消息缺口时，说明检测到了对方或通信连接发生了严重异常，建议接收方终止该会话并断开TCP
连接。如果接收方为会话的发起方，则应根据需要重建会话。
4.1.8 可能的消息重复传送
本会话协议采用TCP连接作为底层通信机制，会话双方在建立TCP连接之后，通过Logon消息进行序
号协商，其后则是基于TCP进行的连续通信，正常情况下，不应该出现前面消息丢失却收到后面消息的
情形，所以：
a) 在发现入向消息序号缺口时，LFIXT 参与者不应发送重传请求，应回送 Logout 后直接断开连
接；
b) 允许在入向消息中出现重传请求，比如基于 FIXT 的通信对手方虽然收到前面的消息但其自己
没保存，并期望能按 FIXT 会话层协议的方式通过重传请求取回，对此 LFIXT 参与者将简单回
送 消息予以回应；
c) 允许在入向消息中出现的消息，比如基于 FIXT 的通信对手方虽未收到本方发
出的重传请求，但仅仅因为怀疑本方可能错过某些消息，而向本方发送这类的消息。
根据FIXT标准，除了消息之外，其他管理消息理论上都不应被重发，而是通过发送带有同样
消息序号的、带有标志的消息对原消息进行替代。在此过程中，被替代
的消息本身虽然仍然以同样的消息序号、带上同样被置位的标志出现，
也被FIXT标准解释为“替代”而非“重发”。
4.1.9 可能的消息重复发送
在本标准中，应用层重发的标志应在应用层协议中明确设置，而不应该体现在会话层消息的标志位
上。由于互操作的对方应遵从同样的应用层协议，因此本标准将不会给出向消息打上任何
本标准允许在入向消息头中出现PossibleResend标志，但将忽略该标志，直接将不附带该标志的消
息交由应用层处理。
4.1.10 消息完整性
消息数据内容的完整性可以用两种方式来验证：验证消息长度及字符的简单校验和。
消息长度被包括在字段中，可以通过清点消息之中跟在字段之后、直至并包
括直接先于CheckSum域号(‘10=’)出现的那个域界定符< SOH >之间的字符来验证。
校验和的验证方法是：从消息头中‘8=’中的‘8’开始、直到并包括直接先于域号
出现的< SOH >字符，将每个字符的二进制值加总后，将计算值的最低8位同字段中的值进行比较。
4.1.11 混乱的消息
当至少出现以下情形之一时，一条消息被称为“混乱的”：
4.1.12 消息确认
由于本标准是基于乐观的消息传输模式，通过监视消息序号发现缺口，不支持对每个消息收发的确
认。但大量消息收发的确认可在应用层定义，并在应用层接受或拒绝。
4.1.13 加密
LFIXT会话层不对数据进行加密处理，会话双方可考虑使用通信层的加密机制，比如使用建构于TCP
之上的TLS通信加密机制。
4.2 会话管理
4.2.1 会话和连接
本标准采用TCP连接作为底层通信机制。
若LFIXT参与方作为会话的主动发起方，应在每次新建TCP连接之后通过置位序号重设标志
的Logon消息来将起始消息序号重置回1，此时会话和TCP连接是一一对应的。
虽然本标准可以被设计成底层使用两个独立的TCP连接，每个连接都以单工模式工作，但由于在TCP
连接上实现全双工的通信并不困难且维护简单，因此本标准规定：对于单个会话而言，同时只使用一个
全双工的TCP连接。
若LFIXT参与方作为会话的接收方，由于该会话的发起方可能是标准的FIXT，此时建立的会话可以
跨越多个TCP连接。
在单次TCP连接内部，每个会话都分为三个部分：建立会话、消息交换、终止会话。
4.2.2 建立会话
4.2.2.1 会话步骤
建立会话包含三个内部步骤：建立连接、身份认证、消息同步。
4.2.2.2 建立连接
会话的发起方与接受方应先建立 TCP 连接。LFIXT 参与方在 TCP 连接建立后，应当总是初始化。
4.2.2.3 身份认证
会话发起方发送登录消息（Logon），会话接受方认证发起方身份的合法性。处理逻辑如下：
a) 如果发起方身份通过认证，则接受方发送一个登录消息作回应。
b) 如果认证失败，会话接受方则在可选地发送一个含失败说明的注销消息（Logout）后关闭连接。
发送注销消息并非是必须的，因为这样做会消耗一个序号，在某些情况下可能会引起其他问题。
c) 会话发起方应等待来自接受方的确认 Logon 消息，方可向接受方发送其他消息。否则，接受方
可能尚未准备好接收它们。
d) 在发起方被认证后，接受方将立即回应一个确认Logon消息。发起方将把从接受方返回的Logon
消息作为“一个会话已经建立”的确认。
4.2.2.4 消息同步
本标准并不提供真正的会话层重传机制，因此LFIXT参与方作为会话的发起方时，可通过会话重置
消息将会话双方的消息序号重置，来完成会话层消息同步。
LFIXT参与方作为会话接受方时，可以利用Logon消息中的来完成会话层消
息同步。这种方式提供了对FIXT会话协议的消息同步的兼容，具体机制见4.3.2登录消息处理。
4.2.3 消息交换
在建立会话之后，会话双方可以开始进行正常的消息交换。交换的消息包括“管理消息”和“应用
消息”，本标准仅对管理消息进行描述。
4.2.4 注销会话
LFIXT会话的正常结束是通过连接双方互相发送注销消息（Logout），注销时不需要进行消息缺口
检查。若结束时没有收到回送的注销消息（Logout），则把对方视作已注销。除此之外的其它方式的会
话结束视为非正常，并应按错误来处理。
在结束会话之前，注销消息（Logout）的发起方应等待对方回送的注销消息（Logout）。如果接收
方在一定时间内没有答复，那么会话就可以立即中断。注销不影响任何业务层消息的状态。所有有效的
业务层消息都可在注销（Logout）之后执行。
4.3 恢复
4.3.1 会话恢复机制概述
本标准的会话层恢复机制是为了与FIXT会话协议兼容，不能作为真正的消息恢复机制使用，会话对
端应通过应用层的消息恢复机制来获得缺失的数据。
LFIXT参与方只在建立会话阶段存在消息序号同步，在会话持续期间不提供真正的消息恢复，而是
简单地通过回应消息来打发消息重传请求。
4.3.2 登录消息处理
LFIXT参与方作为会话接受方时，只需将本方NxtIn设置为发起方Logon消息设置为发起方Logon
消息中的即可。会话接受方不需要检查任何缺口，会
话接受方也不会向发起方请求重传任何消息。如果会话发起方没有提供字段，
则会话接受方的NxtOut设置为1。
4.3.3 重传请求消息处理
LFIXT参与方不会主动发送重传请求，但可能收到FIXT参与方发送的重传请求。当LFIXT参与方收到
重传请求时，会使用消息重置发送方序号，而不会提供历史消息的重传。
4.3.4 序号重设消息处理
LFIXT参与方收到序号重设消息时，会根据序号重设消息中的来重置本方。
5 消息规范
5.1 消息结构
5.1.1 消息的组成部分
每一条消息都由消息头、消息体、消息尾组成。消息总是由标准消息头开始，标准消息尾结束。
5.1.2 消息头
会话双方所有交换的消息都具有标准的消息头，消息头所包含的各字段见表1所示。
每一个消息都由一个标准消息头开始。消息头规定了消息的类型、长度、目的地、顺序号、起始点
和时间等数据域，均不进行会话层的加密传输。
其中有两个域用于消息重发。当作为会话级事件的结果而重复传送消息时，被设置为Y，
发送时沿用原来的消息序号；当应用层重新发送消息时，应使用新的消息序号，并通知会话层将
设置为Y。接收者应按以下方法处理上述消息：
a) 如果以前曾经收到过带有该消息序号的某条消息，则忽略本消息，如果不是，
则按正常步骤处理。
b) 不附带本标志地将消息传递给应用层，由应用层根据业务逻辑自行确定此前是
否收到该消息。
5.1.3 消息尾
会话双方所有交换的消息具有见表2所示标准的消息尾。每一个消息（管理或应用消息）都用一个
消息尾终止。消息尾可用于分隔多个消息，包含有3位数的校验和值。其字段说明见表2。
5.2 管理消息
5.2.1 管理消息和两种模式的关系
本标准支持FIXT的所有管理消息，但不会主动发送所有管理消息。
本标准分两种模式：精简模式和兼容模式，各自有不同的使用范围。
已知通信对手方为LFIXT参与者时，可以采用精简模式，此时只需要支持见表3所示消息的接收和发
送处理。此时由于本方不会主动发送，因此根据协议也不会触发对方回应
因此不需要处理入向的消息。
5.2.2 心跳消息
会话双方都可借助消息来检测当前使用的TCP连接的状态，因此当任何一方处于数据发送
空闲期时，都需要定时发送消息以供检测链接的健康度，故会话双方都应支持心跳信号的主
动发送，心跳消息字段见表6所示。接收方如果在两倍的内没有收
到来自对方的心跳消息，就认为连接失败，此时可以不发送消息，立即关闭TCP连接。
本标准不会主动发......
|