JR T 0066.1-2019 《银行间市场业务数据交换协议第1部分：语法、结构与会话层》.pdf

《JR T 0066.1-2019 《银行间市场业务数据交换协议第1部分：语法、结构与会话层》.pdf》由会员分享，可在线阅读，更多相关《JR T 0066.1-2019 《银行间市场业务数据交换协议第1部分：语法、结构与会话层》.pdf（41页珍藏版）》请在麦多课文档分享上搜索。

1、ICS 35.240.40 A 11 JR 中华人民共和国金融行业标准 JR/T 0066.12019 代替JR/T 00662011 银行间市场业务数据交换协议 第1部分：语法、结构与会话层 Interbank market information exchange protocol Part 1：Syntax， structure and session layer 2019 - 01 - 08发布 2019 - 01 - 08实施 中国人民银行 发布 JR/T 0066.12019 目 次 前言 . II 1 范围 . 1 2 规范性引用文件 . 1 3 术语和定义 . 1 4 报文语法

2、与结构 . 2 5 会话传输 . 14 6 会话管理 . 15 7 会话类报文与组件 . 24 附录A（规范性附录） 域字典 . 32 参考文献 . 37 I JR/T 0066.12019 前 言 JR/T 0066银行间市场业务数据交换协议分成3部分： 第1部分：语法、结构与会话层； 第2部分：应用层； 第3部分：适流表示层。 本部分为JR/T 0066的第1部分。 本部分依据GB/T 1.12009给出的规则起草。 本部分代替JR/T 0066 2011银行间市场业务数据交换协议的协议语法结构、会话机制和会话 层消息相关内容，未被代替的内容纳入JR/T 0066的第2部分。本部分与JR/

3、T 00662011的替代部分相 比，除编辑性修改外主要技术变化如下： 增加了规范性引用文件（见章节2）； 修改和新增了部分术语和定义（见章节3，2011版的章节2）； 修改了报文语法与结构的内容（见章节4，2011版的第4章节和5.1、5.2、5.3）； 修改了会话传输的内容（见章节5，2011版的章节3.1、3.2、3.3、3.4、3.5、3.6和3.7）； 修改了会话管理的内容（见章节6，2011版的3.8和3.9）； 修改了会话类报文与组件的内容（见章节7，2011版的5.4）； 增加了区块链扩展应用以适应国际技术发展（见4.7和7.2.2）。 本部分由中国外汇交易中心暨全国银行间同业

4、拆借中心提出。 本部分由全国金融标准化技术委员会（SAC/TC 180）归口。 本部分负责起草单位：中国外汇交易中心暨全国银行间同业拆借中心。 本部分参与起草单位：中国人民银行科技司。 本部分主要起草人：许再越、姚前、杨富玉、朱荣、叶胜国、姜才康、王成勇、胡剑、李正、陈彬、 胡卫平、沈峻、崔嵬、郦永达、余波、曲维民、孙小林、沈薇薇、茅廷、杨帆、夏志江、孙英昊、包晓 晶、赵俊锋、卢艳民、崔奇、邓钢轶、严璐祎、沈叶。 JR/T 0066于2011年6月2日首次发布，本次为第一次修订。 II JR/T 0066.12019 银行间市场业务数据交换协议 第1部分：语法、结构与会话层 1 范围 JR/T

5、 0066的本部分规定了银行间市场参与方之间进行银行间交易所需的会话层通讯协议 （Interbank Market Information Exchange Protocol Transport，简称IMIXT），包括报文语法与结 构、会话可靠传输规范、会话管理规范、会话类报文与组件等。 本部分适用于银行间市场参与方之间的基础会话通讯数据交换。本部分应用于银行间市场机构间的 业务数据交换协议（Interbank Market Information Exchange Protocol，简称IMIX）报文传输交互， 银行间市场机构包括且不限于中介服务机构、会员机构、使用本部分的其他机构等。 2

6、规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。 凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 GB/T 2659 世界各国和地区名称代码 GB/T 12406 表示货币和资金的代码 JR/T 0066.22019 银行间市场业务数据交换协议 第2部分：应用层 3 术语和定义 下列术语和定义适用于本文件。 3.1 域界定符 field separator 报文中所有的域都有一个分隔符来界定分隔。 注：分隔符为ASCII码0 x01，JR/T 0066中域界定符以表示。 3.2 重复组 repeating group

7、 由重复次数和若干组同类数据组成的域集合。 3.3 组件 component 会话报文和应用报文中，按照一定业务逻辑组成的域集合。 3.4 报文序号 message sequence number 1 JR/T 0066.12019 报文传输过程中，用于监测报文传输连续性的数值。 注：通过该数值判断交换数据是否丢失。 3.5 心跳 heart beat 报文发起方和接收方在报文交换空闲期，通过产生规律性心跳报文保持通讯连接的场景。 3.6 重复发送 possible duplicate 因响应一个重发请求或者不确定对方是否收到已发报文，导致重复发送报文的场景。 注：该场景下的报文应设置“可能重

8、复标志”（PossDupFlag =Y）。 3.7 重新发送 possible resend 因发送方或接收方应用需要，由报文发送方重新生成报文并发送的场景。 注：该场景下的报文应设置“可能重发标志”（PossResend=Y）。 3.8 序号重设 sequence reset 发送方用于设置预期报文序号的报文。序号重设报文有两种模式：序号重设-缺口填补 （SeqReset -Gap Fill）、序号重设-重置（SeqReset-Reset）。 注：序号重设-重置（SeqReset -Reset）仅在灾难恢复情况下使用。 3.9 有效IMIX报文 valid IMIX message 按照IM

9、IX协议正确生成的报文。 3.10 发起方 initiator 登录报文的发送方。 3.11 接收方 acceptor 登录报文的接收方。 3.12 区块链 blockchain 一种在对等网络环境下，通过透明和可信规则，构建不可伪造、不可篡改和可追溯的块链式数据结 构，实现和管理事务处理的模式。 4 报文语法与结构 4.1 数据类型 2 JR/T 0066.12019 4.1.1 说明 数据类型用于定义数据域的取值类型，JR/T 0066使用的数据类型由几个基本的数据类型（整数、 浮点数、字符、字符串、数据）和在此基础上扩展的数据类型组成。除“数据”数据类型外，其他数据 类型均以ASCII码

10、字符串表示。 4.1.2 整数 int 无逗号和小数位的数值，可表示正负（ASCII码字符“-”，“0”至“9”组成）。符号占据一个字 符位置。前置字符可置零（例如“00023 ”=“23”）。 整数类型的扩展定义： a) 长度 Length：以整数表示字节为单位的数据长度，正数； b) 重复数 NumInGroup：以整数表示重复组的个数，正数； c) 报文序号 SeqNum：以整数表示报文序号，正数； d) 域号 TagNum：以整数表示的域号（或称Tag），正数，首位不能为零； e) 月日期号 DayOfMonth：以整数表示的月份中第几天，取值1至31。 4.1.3 浮点数 float

11、 含有可选的小数部分，可表示正负（ASCII码字符“-”，“0”至“9”和“.”组成）。前置字符 可置零（例如“0023”=“23”），小数部分后置字符可置零（例如“23.0” =“23.0000 ”=“23”）。 浮点数类型的扩展定义： a) 量 Qty：股份数量、资产数量等，可有小数部分； b) 价格 Price：小数位数可变； c) 价格偏移量 PriceOffset：代表价格偏移量的浮点域； d) 金额 Amt：典型的价格与数量相乘结果，如成交金额； e) 百分比 Percentage：小数表示方法，例如.05代表5%。 4.1.4 字符 char 除界定符外所有字母字符和标点字符，区

12、分字母大小写。 字符类型的扩展定义是布尔 Boolean：该域取值有两个字符（“Y” =True/Yes，“N” =False/No）。 4.1.5 字符串 String 除界定符外由数字、字母、符号组成的一串字符，区分字母大小写。 字符串类型的扩展定义： a) 多元值字符串 MultipleValueString：用空格分隔（例如10243=D2 M3 Y3）； b) 国家 Country：取值范围见GB/T 2659（例如470=CHN）； c) 字符串货币类型 Currency：取值范围见GB/T 12406（例如15=CNY）； d) 交易所或市场编号 Exchange：字符串（例如1

13、301=2）； e) 年月 M onth-year：格式YYYYMM，YYYY=0000-9999，MM=01-12（例如200=201710）； f) 国际标准时时间戳 UTCTimestamp：格式YYYYMMDD-HH:MM:SS（秒）或YYYYMMDD-HH:MM:SS.sss （毫秒），YYYY=0000-9999，MM=01-12，DD=01 -31，HH=00-23，MM=00-59，SS=00 -59（秒）， sss=000-999（毫秒）（例如60=20171012-11:40:00或20171012-11:40:00.123）； g) 国际标准时时间 UTCTimeOnly

14、：格式HH:MM:SS 或HH:MM:SS.sss，HH=00-23，MM=00-59， SS=00-59(秒)，sss=000-999(毫秒)（例如10318=11:40:00或11:40:00.123）； 3 JR/T 0066.12019 h) 本地市场日期 LocalMktDate：格式YYYYMMDD，YYYY=0000-9999，MM=01- 12，DD=01-31（例如 916=20171012）； i) 国际标准时日期 UTCDate：格式YYYYMMDD，YYYY=0000-9999，MM=01-12，DD=01-31（例如 75=20171012）。 4.1.6 数据 Da

15、ta 无格式和内容限制的原始数据，包含长度域和数据域两个部分，数据域数据可包含域界定符SOH、 特殊符号等，长度域指明数据域的字节数（注意：该字节数的计算不计域界定符SOH）。 示例：1401为长度域，1402为数据域。 数据样例：1401=5 1402=XX =X 4.2 域 4.2.1 域的定义 域是基本的数据元素。传输过程中，域由域号、等号、域值组成，即域号=域值。域字典部分详细 定义了本部分所涉及到的所有域的数据类型和取值范围，见附录A。 4.2.2 域的使用 在报文中，域的使用有三种方式：必需的、非必需的、条件限制选择（即根据其他相关域的存在与 否或取值来决定）。 条件限制选择域的示

16、例见表1。当628、629、630存在取值时，则627应有值；当628、629、630不存 在取值时，则627也可为空。627即为条件限制选择域。 表1 条件限制选择域的示例 域号/嵌套组件名 域名 必需域 627 NoHops - 628 HopCompID Y - 629 HopSendingTime - 630 HopRefID 4.2.3 自定义域 如JR/T 0066中定义的域无法满足使用，可扩展定义新的域，即自定义域。 JR/T 0066使用者之间可自行约定自定义域，自定义域的域号不应与JR/T 0066中定义的域号重复， 且应大于10000。 4.2.4 域界定 报文中所有的域（

17、包含data类型数据域）都有一个分隔符来界定分隔，该分隔符就是ASCII码0 x01 （以表示）。 任何报文应由多个“域号=值”的基本结构组成，用域界定符分隔。报文组成结构见图1。 4 JR/T 0066.12019 域号=域值域号=域值 图1 报文组成结构 4.3 IMIX报文组成规则 报文由报文头、报文体和报文尾组成。每个组成部分都由一系列“域号=值”组成，应遵循以下规 则： a) 开始部分应是报文头，随后是报文体，最后是报文尾； b) 报文头的前3个域的次序不应改变：起始串（Tag#8）、报文体长度（Tag#9）、报文类型（Tag#35）； c) 报文尾的最后一个域应是校验和域（Tag#

18、10）； d) 重复组中，域出现的顺序应遵循该重复组在报文或组件中定义时的次序； e) 除重复组域外，任一域号在一条报文内只能出现一次，否则视为错误。 报文格式示例见图2。 图2 报文格式示例 4.4 重复组 重复组是由重复次数和若干组同类数据组成的域集合。 重复组内，同类数据域集合的第一个域是必需的。如果域名起始为“No”字符、用于指明重复次数 的域的域值大于0，则该域后所列的第一个域为必需域。 重复组示例见表1。628为必需域，根据628判断新的628、629、630组成的域集合的开始。 JR/T 0066通过缩进的符号“- ”对报文定义内的重复组进行标注。重复组可嵌入其他重复组。JR/T

19、 0066通过重复组结构中增加被嵌套的重复组名称，对被嵌套的重复组进行标注。 4.5 安全与加密 由于报文可能在公共网络或不安全的网络上传输交换，因此对相关的敏感数据宜进行加密处理。具 体加密的方法由连接双方达成的协议而定，同时加密方法应符合国家密码管理机构的规定。报文内除某 些需要公开识别的域以明文传输外，其他任何域都可加密放置在密文数据域（SecureData）内。这些被 8=IMIX1.09=xxx35=849=CFETS56=29000881100000000000057=MHBJ.D EALERMHBJ34=1352=20070913-10:20:59347=UTF-811=MHBJ

20、_ORDER_00215=AUD17=5.1.329331=0.77132=5000054=160=20061122-10:21:3463=064=2006112475=20061122120=AUD150=F194=0.7711056= 3855010176=1210038=2210042=MT10317=510315=210296=200611 241028438547.522=548=AUDUSD=CFHA55=AUD.USD453=2448=1190 00043010000000000452=I14802=3523=CCCB.DEALERCCCB803=101523= CCCB803=

21、102523=ChangshaCityCommercialBank803=5448=290008811000000 000000452=I13802=3523=MHBJ.DEALERMHBJ803=101523=MHBJ80 3=102523=Mizuho Corporate Bank Beijing803=510=XXX 5 JR/T 0066.12019 加密的域也可同时保留明文的表示方式。如果报文的重复组内有部分数据需要加密，则应对整个重复组 加密。本部分还提供一些域用以支持数字签名、密钥交换和正文加密等安全技术。 加密方案有三种： a) 将安全敏感的域加密后移至SecureData域；

22、 b) 将所有可加密的域加密后移至SecureData域； c) 将所有可加密的域加密后移至SecureData域，同时这些域以明文在报文中重复出现。 4.6 数据完整性 数据的完整性通过两个方法保证：报文体长度以及校验和的验证。 报文体长度以BodyLength域来表示，其值是计算出的报文长度域后面的字符数，包含紧靠校验和域 “10=”之前的域界定符。校验和是把每个字符的二进制值从报文开头“8= ”中的“8”开始相加， 一直加到紧靠在校验和域“10= ”之前的域界定符，然后取按256取模得到的结果。校验和域位于报文的 最末，校验和的计算是在加密之后进行的。为便于传输，校验和应按可打印字符进行

23、发送，所以应转换 为以ASCII码编码的3个值。 示例：如果校验和计算出来是274，则按256取模就得到18，即(256+18)mod 256=18。这个值将会以|10=018|传输， 其中“10=”是校验和域的标志。 产生校验和域的一个示范代码片段见图3。 图3 校验和域示范代码片段 4.7 IMIX报文结构 对于每一条IMIX报文，它的报文结构分解见图4。 char *GenerateCheckSum(char *buf, long bufLen) static char tmpBuf4; long idx; unsigned int cks; for( idx = 0L, cks = 0

24、; idx bufLen; cks += (unsigned int)buf idx+ ); sprintf( tmpBuf, “%03d”, (unsigned int)( cks % 256 ) ); return( tmpBuf ); ; 6 JR/T 0066.12019 IMIX Message IMIX报文 Header 标准报文头 Trailer 标准报文尾 Body 报文体 域8 域9 域35 域 Component 组件 Repeating Group 重复组 域10 Group Block1 组块1 域 域 域域 域 Group Block2 组块2 域 域 Group B

25、lock3 组块3 域 域 说明： 域 表示某个域； 重复组 表示重复组，可由多个重复组块组成； 组块 表示重复组中每块重复部分，也是由域块组成； 组件 表示多个域的集合，这些域所代表的含义之间具有关联性。 图4 IMIX报文结构 面向区块链技术运作的数据整体结构见图5。 7 JR/T 0066.12019 区块链 区块链 报文头 报文头 负载体 负载体 区块头 区块头 区块体 区块体 版本 版本 前区块头哈希 前区块头哈希 默克尔根哈希 默克尔根哈希 Time 时间戳 Time 时间戳 Bits 当前目标HASH值 Bits 当前目标HASH值 Nonce 随机数 Nonce 随机数 魔数

26、魔数 命令名 命令名 负载大小 负载大小 校验码 校验码 图5 区块链整体结构 区块链整体结构包括报文头和负载体。不同的负载体类型可满足各类场景传输的需求，如获取区块、 获取数据、交易单等。图5为传输区块头和交易单的区块时的区块链整体结构。当负载体无数据定义时， 可仅传输报文头。 根据区块链的数据结构定义，其数据类型和组织方式并未超出现有IMIX体系范畴。按照图4给出的 IMIX报文结构，应用区块链技术的IMIX报文结构见图6。 8 JR/T 0066.12019 负载体组件 区块链报文头组件 IMIX Block Header 标准报文头 Trailer 标准报文尾 Body 报文体 域8

27、域9 负载大小 区块头组件 域10 版本 前区块头哈希 魔数 默克尔根哈希 校验码 命令名 区块体 域35 说明： 域 表示某个域； 组件 表示多个域的集合，这些域所代表的含义之间具有关联性。 图6 应用区块链技术的IMIX报文结构 图6为传输区块头和交易单区块时的IMIX报文结构。根据具体场景应用需求，可使用不同负载体类 型的组件。 IMIX协议中，固定分配2000021000域号段用于区块链数据内容的表达。 4.8 标准报文头 9 JR/T 0066.12019 4.8.1 概述 每个会话报文或应用报文都有一个报文头，该报文头指明报文类型、报文体长度、发送目的地、报 文序号、发送起始点和发

28、送时间。 4.8.2 标准报文头格式 标准报文头见表2。 表2 标准报文头 域号/嵌套组件名 域名 必需域 备注 8 BeginString Y 起始串定义报文的协议版本（不应加密，报文的第一个域）。 9 BodyLength Y 报文体长度（不应加密，应是报文的第二个域）。 34 MsgSeqNum Y 报文序号（可加密）。 35 MsgType Y 报文类型（不应加密，应是报文的第三个域）。 43 PossDupFlag 可能重复标志，重复发送时，作此标记（可加密）。 49 SenderCompID Y 发送方标识符（不应加密）。 50 SenderSubID 发送方子标识符（可加密）。

29、52 SendingTime Y 发送时间（可加密）。 56 TargetCompID Y 接收方标识符（不应加密）。 57 TargetSubID 接收方子标识符（可加密）。 90 SecureDataLen 用于标识报文加密部分的长度时必需（不应加密）。 91 SecureData 报文体加密时必需。紧跟在SercureDataLen域之后。 97 PossResend 可能重发标志（可加密）。 115 OnBehalfOfCompID 最初发送方标识符（可加密），用于经第三方发送。 116 OnBehalfOfSubID 最初发送方子标识符（可加密）。 122 OrigSendingTi

30、me 原始发送时间（可加密）。 128 DeliverToCompID 最终接收方标识符（可加密），用于经第三方发送。 129 DeliverToSubID 最终接收方子标识符（可加密）。 142 SenderLocationID 发送方的LocationID（如：地理位置和（或）席位（desk）（可 加密）。 143 TargetLocationID 接收方LocationID（如：地理位置和（或）席位（desk）（可 加密）。 145 DeliverToLocationID 最终接收方的LocationID（如：地理位置和（或）席位（desk） （可加密）。 212 XmlDataLen

31、当标识XmlData报文体长度时必需（可加密）。 213 XmlData 包含XML格式的报文块（如IMIXML）；总紧跟在XmlDataLen（可 加密）之后。 347 MessageEncoding 在报文的“Encode”域中使用的报文编码格式（非ASCII编码）， 使用编码域时必需。 369 LastMsgSeqNumProcessed 最后处理报文序号（可加密）。 1128 ApplVerID 使用SP标识方法标明应用版本，ApplVerID用于一个特定报文 的场景。 10 JR/T 0066.12019 域号/嵌套组件名 域名 必需域 备注 1129 CstmApplVerID 用

32、于支持客户共同协商认可的功能。 1156 AppIExtID 组件 为历史跳跃信息重复组，记录报文经第三方发送的历史。 每次经第三方发送为一个跳跃，仅当OnBehalfOfCompID使用时 有效，主要用于跟踪报文的路径。注意：一些市场条例或者对 手方可能要求追踪hops报文。 4.8.3 标准报文头在报文传输的应用 4.8.3.1 点对点传输 表3和表4展示了在两个市场参与方之间的单个点对点IMIX会话中如何使用SenderCompID、 TargetCompID、SenderSubID、TargetSubID域。SenderSubID为SenderCompID的子机构，TargetSubI

33、D 为TargetCompID的子机构。 两个主机构之间的单个点对点IMIX会话传输示例见表3。假设A为卖方主机构，B为买方主机构。 表3 点对点传输示例表（主机构之间） SenderSubID SenderCompID TartgetCompID TargetSubID A到B A B B到A B A 两个子机构之间的单个点对点IMIX会话传输示例见表4。假设A1为卖方子机构，A为卖方主机构，B1 为买方子机构，B为买方主机构。 表4 点对点传输示例表（子机构之间） SenderSubID SenderCompID TartgetCompID TargetSubID A1到B1 A1 A B

34、 B1 B1到A1 B1 B A A1 4.8.3.2 报文转发 由于两端之间的报文通过第三方进行转发，第三方可与其他第三方连接，在报文发起方和最终的接 收方间形成多点的链条。SenderCompID、SenderSubID、TargetCompID、TargetSubID、DeliverToCompID、 DeliverToSubID、OnBehalfOfCompID和OnBehalfOfSubID域用于报文路由。这些域的使用方法见表5，其 中A为卖方，B和C为买方，Q为第三方。 表5 报文转发示例表 SenderCompID OnBehalfOf CompID TargetCompID D

35、eliverTo CompID HopCompID HopSendingTime 从A通过Q到B 1 A到Q A Q B 2 Q到B Q A B Q A的发送时间 B通过Q响应A 11 JR/T 0066.12019 SenderCompID OnBehalfOf CompID TargetCompID DeliverTo CompID HopCompID HopSendingTime 1 B到Q B Q A 2 Q到A Q B A Q B的发送时间 A通过Q发送到B和C 1 A到Q A Q B 2 Q到B Q A B Q A的发送时间 3 A到Q A Q C 4 Q到C Q A C Q A的

36、发送时间 B和C通过Q发送到A 1 B到Q B Q A 2 Q到A Q B A Q B的发送时间 3 C到Q C Q A 4 Q到A Q C A Q C的发送时间 注：由于在一个给定的IMIX会话中，一些域（如在一个新Order指令中的ClOrdID）应是唯一的。因此，当使 用O nBehalfOfCompID域（或DeliverToCompID域）进行寻址时，应在OnBehalfOfCompI D域（或 DeliverToCompID域）之后加上原值。这样，如果A发送报文到Q的ClOrdID为“123 ”，则Q将“A -123” 作为ClOrdID的值发送到C，以确保唯一性。 报文转发场景示

37、例见表6。 表6 报文转发场景示例 示例 条件/触发条件 预期行为 支持第三方机构编 码 收到报文中，OnBehalfOfCompID和 DeliverToCompID域值与会话配置中的 OnBehalfOfCompID和DeliverToCompID域值 相同。 接收报文。 支持第三方机构编 码 收到报文中，OnBehalfOfCompID或 DeliverToCompID域值与会话配置中的 OnBehalfOfCompID和DeliverToCompID域值 不同。 发送拒绝报文，描述无效的 OnBehalfOfCompID或DeliverToCompID 域值（sessionReject

38、Reason=“CompID problem”)。 4.8.4 接收标准报文头场景示例 接收标准报文头场景见表7。 表7 接收标准报文头场景示例 示例 条件/触发条件 预期行为 接收标准报文头 接收预期的MsgSeqNum域值。 接收报文的MsgSeqNum域值。 MsgSeqNum域值比预期高。 发起重发请求报文。 MsgSeqNum域值比预期低并且PossDupFlag 域没有设置为Y。 例外：S eqReset被重置。 a）发送序号重设-重置报文，将对端下一个 预期的报文序号重置成1； b）本方将下一个预期接收报文序号重置成 12 JR/T 0066.12019 示例 条件/触发条件 预

39、期行为 1。 接收到异常的报文 a 。 发送拒绝报文。 PossDupFlag设置为Y，OrigSendingTime少 于或等于SendingTime，并且MsgSeqNum域值 低于预期。 注意：OrigSendingTime应早于SendingTime。 接收并处理该报文。 PossDupFlag设置为Y，OrigSendingTime大 于SendingTime，并且MsgSeqNum与预期相 同。 注意：OrigSendingTime应早于SendingTime 除非该报文在同一秒被重新发送。 a）发送拒绝报文，描述错误的SendingTime （SessionRejectReaso

40、n=“SendingTime accuracy problem”）； b）发出登出报文，等待登出报文响应，接 收到登出报文响应后断开连接。 PossDupFlag设置为Y且OrigSendingTime 值未被指定。 注意：响应重发请求报文时，由于报文的最 初发送时间不是当前SendingTime值，因此 应发送OrigSendingTime，并且设置 PossDupFlag=“Y”。 发送拒绝报文，描述错误的 OrigSendingTime（SessionRejectReason= “Required tag missing”）。 接收BeginString的值与会话指定值匹配。 接收报文的

41、BeginString域值。 接收到的BeginString的值与会话指定值不 匹配。 a）忽略该报文； b）设置下一个报文序号自增1； c）断开连接。 接收SenderCompID和TargetCompID的值与 会话指定值匹配。 接收报文的SenderCompID和TargetCompID 域值。 接收到的SenderCompID和TargetCompID值 与会话指定值不匹配。 a）忽略该报文； b）断开连接。 接收到正确的BodyLength值。 接收报文中的BodyLength域。 接收到错误的BodyLength值。 重新计算BodyLength值，并赋值。 接收的SendingT

42、ime的值符合规定时间 b 。 接收报文的SendingTime域。 接收的SendingTime的值不符合规定时间。 a）发送拒绝报文，描述不准确的 SendingTime（SessionRejectReason= “SendingTime accuracy problem”）； b）发送附有错误SenderCompID或 SendingTime值的登出报文； c）（非必需）等待登出报文响应（注意： 可能传来有错误的SendingTime值）。 接收到有效的MsgType的值（数据字典定义）。 接收报文的MsgType域。 接收到无效的MsgType的值（数据字典未定 义）。 a）忽略该报文

43、； b）设置下一个报文序号自增1。 BeginString、BodyLength和MsgType是报文 的前三个域。 接收报文。 BeginString、BodyLength和MsgType不是报a）考虑报文存在异常，忽略该报文； 13 JR/T 0066.12019 示例 条件/触发条件 预期行为 文的前三个域。 b）设置下一个报文序号自增1。 a 异常报文是指下述情况： a）BeginString（tag#8）非报文中的第一个域，或不符合8=IMIX*.n.m.的格式； b）BodyLength（tag#9）非报文中的第二个域，或字节数不正确； c）MsgType（tag#35）非报文中的

44、第三个域； d）Checksum（tag#10）非最后一个域，或其值非有效值。 b 规定时间指的是两边的系统时间一致并且SendingTime应为当前时间。 4.9 标准报文尾 4.9.1 概述 每一个会话报文或应用报文都有一个报文尾，并以此终止。报文尾可用于分隔多个报文，包含有3 位数的校验和值。 4.9.2 标准报文尾格式 标准报文尾格式见表8。 表8 标准报文尾 域号/嵌套组件名 域名 必需域 备注 89 Signature 数字签名（不可加密）。 93 SignatureLength 数字签名长度（不可加密）。 10 CheckSum Y 校验和，报文的最末域（不可加密）。 4.9.3

45、 标准报文尾场景示例 接收标准报文尾场景示例见表9。 表9 接收标准报文尾场景示例 示例 条件/触发条件 预期行为 接收标准报文尾 有效的CheckSum域值。 接收报文。 无效的CheckSum域值。 a）考虑报文存在异常，忽略该报文； b）设置下一个报文序号自增1。 异常的报文。 a）考虑报文存在异常，忽略该报文； b）发送拒绝报文，其中Text域描述错误 情况。 CheckSum在报文的末尾域，域值的长度 是3且以为结尾。 接收报文。 CheckSum不在报文的末尾域，或域值的 长度不是3，或不以为结尾。 a）考虑报文存在异常，忽略该报文； b）设置下一个报文序号自增1。 5 会话传输

46、14 JR/T 0066.12019 5.1 会话机制 IMIX会话由一个或多个IMIX连接（IMIX Connection）组成。IMIX连接由三部分组成：登录（logon）、 报文传输（message exchange）和登出（logout）。一个IMIX会话可多次登录。 5.2 报文序号 任何一条报文都被分配一个唯一的报文序号来加以标识。报文序号在每次会话过程中从1开始，在 整个会话过程中连续递增，直到该会话过程全部结束。 5.3 心跳 在报文交换的空闲期间，连接双方将在规定的时间间隔内发出心跳报文。通过心跳报文可监测通讯 连接的状态。 5.4 报文丢失 报文接收方应监测报文是否丢失并加

47、以处理。 5.5 报文重复发送 报文发送方响应一个重发请求而重复发送报文时应在被重发报文内加上可能重复标志 （PossDupFlag=Y），应重新计算校验和。报文接收方检查该报文，如果曾经接收过，则忽略报文；如 果未曾收到过，则按正常步骤处理。 5.6 报文重新发送 报文发送方应设置可能重发标志（PossResend=Y），设置新的报文序号，重新计算校验和，重新发 送报文。报文接收方收到该类报文后，应通过查询报文内的域（如订单编号等）来确定此前是否收到过 该报文。 5.7 报文确认 报文接收方通过监测报文序号缺口来识别正常传送过程中的错误，IMIX应用层报文确认处理见JR/T 0066.22019。 6 会话管理 6.1 概述 连接双方各自维护一组连续的报文序号实现会话维持。会话过程分为三个部分：登录、报文交换、 登出。 6