JR∕T 0066.1-2019（代替JR∕T 0066-2011） 银行间市场业务数据交换协议 第1部分：语法、结构与会话层.pdf

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 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 00662011银行间市场业务数据交换协议的协议语法结构、会话机制和会话层消息相关内容，未被代替的内容纳入JR/T 0066的第2部分。本部分与JR/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）。 本部分由中国外汇交易中心暨全国银行间同业拆借中心提出。 本部分由全国金融标准化技术委员会（SAC/TC 180）归口。 本部分负责起草单位：中国外汇交易中心暨全国银行间同业拆借中心。 本部分参与起草单位：中国人民银行科技司。 本部分主要起草人：许再越、姚前、杨富玉、朱荣、叶胜国、姜才康、王成勇、胡剑、李正、陈彬、胡卫平、沈峻、崔嵬、郦永达、余波、曲维民、孙小林、沈薇薇、茅廷、杨帆、夏志江、孙英昊、包晓晶、赵俊锋、卢艳民、崔奇、邓钢轶、严璐祎、沈叶。 JR/T 0066于2011年6月2日首次发布，本次为第一次修订。 II JR/T 0066.12019 银行间市场业务数据交换协议 第 1 部分：语法、结构与会话层 1 范围 JR/T 0066的本部分规定了银行间市场参与方之间进行银行间交易所需的会话层通讯协议（Interbank Market Information Exchange Protocol Transport，简称IMIXT），包括报文语法与结构、会话可靠传输规范、会话管理规范、会话类报文与组件等。 本部分适用于银行间市场参与方之间的基础会话通讯数据交换。 本部分应用于银行间市场机构间的业务数据交换协议（Interbank Market Information Exchange Protocol，简称IMIX）报文传输交互，银行间市场机构包括且不限于中介服务机构、会员机构、使用本部分的其他机构等。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。 凡是注日期的引用文件， 仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 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 由重复次数和若干组同类数据组成的域集合。 3.3 组件 component 会话报文和应用报文中，按照一定业务逻辑组成的域集合。 3.4 报文序号 message sequence number 1 JR/T 0066.12019 报文传输过程中，用于监测报文传输连续性的数值。 注：通过该数值判断交换数据是否丢失。 3.5 心跳 heart beat 报文发起方和接收方在报文交换空闲期，通过产生规律性心跳报文保持通讯连接的场景。 3.6 重复发送 possible duplicate 因响应一个重发请求或者不确定对方是否收到已发报文，导致重复发送报文的场景。 注：该场景下的报文应设置“可能重复标志”（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 按照IMIX协议正确生成的报文。 3.10 发起方 initiator 登录报文的发送方。 3.11 接收方 acceptor 登录报文的接收方。 3.12 区块链 blockchain 一种在对等网络环境下，通过透明和可信规则，构建不可伪造、不可篡改和可追溯的块链式数据结构，实现和管理事务处理的模式。 4 报文语法与结构 4.1 数据类型 2 JR/T 0066.12019 4.1.1 说明 数据类型用于定义数据域的取值类型，JR/T 0066使用的数据类型由几个基本的数据类型（整数、浮点数、字符、字符串、数据）和在此基础上扩展的数据类型组成。除“数据”数据类型外，其他数据类型均以ASCII码字符串表示。 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 含有可选的小数部分，可表示正负（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 除界定符外所有字母字符和标点字符，区分字母大小写。 字符类型的扩展定义是布尔 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：字符串（例如 1301=2）； e) 年月 Month-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：格式 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 数据 Data 无格式和内容限制的原始数据， 包含长度域和数据域两个部分， 数据域数据可包含域界定符 SOH 、特殊符号等，长度域指明数据域的字节数（注意：该字节数的计算不计域界定符SOH）。 示例：1401 为长度域，1402 为数据域。 数据样例：1401=5 1402=XX=X 4.2 域 4.2.1 域的定义 域是基本的数据元素。传输过程中，域由域号、等号、域值组成，即域号=域值。域字典部分详细定义了本部分所涉及到的所有域的数据类型和取值范围，见附录A。 4.2.2 域的使用 在报文中，域的使用有三种方式：必需的、非必需的、条件限制选择（即根据其他相关域的存在与否或取值来决定）。 条件限制选择域的示例见表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 域界定 报文中所有的域（包含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#10）； d) 重复组中，域出现的顺序应遵循该重复组在报文或组件中定义时的次序； e) 除重复组域外，任一域号在一条报文内只能出现一次，否则视为错误。 报文格式示例见图2。 图2 报文格式示例 4.4 重复组 重复组是由重复次数和若干组同类数据组成的域集合。 重复组内，同类数据域集合的第一个域是必需的。如果域名起始为“No”字符、用于指明重复次数的域的域值大于0，则该域后所列的第一个域为必需域。 重复组示例见表1。628为必需域，根据628判断新的628、629、630组成的域集合的开始。 JR/T 0066通过缩进的符号 “-” 对报文定义内的重复组进行标注。 重复组可嵌入其他重复组。 JR/T 0066通过重复组结构中增加被嵌套的重复组名称，对被嵌套的重复组进行标注。 4.5 安全与加密 由于报文可能在公共网络或不安全的网络上传输交换， 因此对相关的敏感数据宜进行加密处理。 具体加密的方法由连接双方达成的协议而定， 同时加密方法应符合国家密码管理机构的规定。 报文内除某些需要公开识别的域以明文传输外，其他任何域都可加密放置在密文数据域（SecureData）内。这些被8=IMIX1.09=xxx35=849=CFETS56=29000881100000000000057=MHBJ.D EALERMHBJ34=1352=20070913-10:20:59347=UTF-811=MHBJ_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=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 域； b) 将所有可加密的域加密后移至 SecureData 域； c) 将所有可加密的域加密后移至 SecureData 域，同时这些域以明文在报文中重复出现。 4.6 数据完整性 数据的完整性通过两个方法保证：报文体长度以及校验和的验证。 报文体长度以BodyLength域来表示， 其值是计算出的报文长度域后面的字符数， 包含紧靠校验和域“10=”之前的域界定符。校验和是把每个字符的二进制值从报文开头“8=”中的“8”开始相加，一直加到紧靠在校验和域“10=”之前的域界定符，然后取按256取模得到的结果。校验和域位于报文的最末，校验和的计算是在加密之后进行的。为便于传输，校验和应按可打印字符进行发送，所以应转换为以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; idx bufLen; cks += (unsigned int)buf idx+ ); sprintf( tmpBuf, “%03d”, (unsigned int)( cks % 256 ) ); return( tmpBuf ); ; 6 JR/T 0066.12019 IMIX MessageIMIX报文Header标准报文头Trailer标准报文尾Body报文体域8域9域35域Component组件Repeating Group重复组域10Group Block1组块1域域域域域Group Block2组块2域域Group Block3组块3域域 说明： 域 表示某个域； 重复组 表示重复组，可由多个重复组块组成； 组块 表示重复组中每块重复部分，也是由域块组成； 组件 表示多个域的集合，这些域所代表的含义之间具有关联性。 图4 IMIX 报文结构 面向区块链技术运作的数据整体结构见图5。 7 JR/T 0066.12019 区块链区块链报文头报文头负载体负载体区块头区块头区块体区块体版本版本前区块头哈希前区块头哈希默克尔根哈希默克尔根哈希Time 时间戳Time 时间戳Bits 当前目标HASH值Bits 当前目标HASH值Nonce 随机数Nonce 随机数魔数魔数命令名命令名负载大小负载大小校验码校验码 图5 区块链整体结构 区块链整体结构包括报文头和负载体。 不同的负载体类型可满足各类场景传输的需求， 如获取区块、获取数据、交易单等。图5为传输区块头和交易单的区块时的区块链整体结构。当负载体无数据定义时，可仅传输报文头。 根据区块链的数据结构定义，其数据类型和组织方式并未超出现有IMIX体系范畴。按照图4给出的IMIX报文结构，应用区块链技术的IMIX报文结构见图6。 8 JR/T 0066.12019 负载体组件区块链报文头组件IMIX BlockHeader标准报文头Trailer标准报文尾Body报文体域8域9负载大小区块头组件域10版本前区块头哈希魔数默克尔根哈希校验码命令名区块体域35 说明： 域 表示某个域； 组件 表示多个域的集合，这些域所代表的含义之间具有关联性。 图6 应用区块链技术的 IMIX 报文结构 图6为传输区块头和交易单区块时的IMIX报文结构。根据具体场景应用需求，可使用不同负载体类型的组件。 IMIX协议中，固定分配2000021000域号段用于区块链数据内容的表达。 4.8 标准报文头 9 JR/T 0066.12019 4.8.1 概述 每个会话报文或应用报文都有一个报文头，该报文头指明报文类型、报文体长度、发送目的地、报文序号、发送起始点和发送时间。 4.8.2 标准报文头格式 标准报文头见表2。 表2 标准报文头 域号/嵌套组件名 域名 必需域 备注 8 BeginString Y 起始串定义报文的协议版本（不应加密，报文的第一个域） 。 9 BodyLength Y 报文体长度（不应加密，应是报文的第二个域） 。 34 MsgSeqNum Y 报文序号（可加密） 。 35 MsgType Y 报文类型（不应加密，应是报文的第三个域） 。 43 PossDupFlag 可能重复标志，重复发送时，作此标记（可加密） 。 49 SenderCompID Y 发送方标识符（不应加密） 。 50 SenderSubID 发送方子标识符（可加密） 。 52 SendingTime Y 发送时间（可加密） 。 56 TargetCompID Y 接收方标识符（不应加密） 。 57 TargetSubID 接收方子标识符（可加密） 。 90 SecureDataLen 用于标识报文加密部分的长度时必需（不应加密） 。 91 SecureData 报文体加密时必需。紧跟在 SercureDataLen 域之后。 97 PossResend 可能重发标志（可加密） 。 115 OnBehalfOfCompID 最初发送方标识符（可加密） ，用于经第三方发送。 116 OnBehalfOfSubID 最初发送方子标识符（可加密） 。 122 OrigSendingTime 原始发送时间（可加密） 。 128 DeliverToCompID 最终接收方标识符（可加密） ，用于经第三方发送。 129 DeliverToSubID 最终接收方子标识符（可加密） 。 142 SenderLocationID 发送方的 LocationID（如：地理位置和（或）席位（desk） ） （可加密） 。 143 TargetLocationID 接收方 LocationID（如：地理位置和（或）席位（desk） ） （可加密） 。 145 DeliverToLocationID 最终接收方的 LocationID （如： 地理位置和 （或） 席位 （desk） ）（可加密） 。 212 XmlDataLen 当标识 XmlData 报文体长度时必需（可加密） 。 213 XmlData 包含 XML 格式的报文块 （如 IMIXML） ； 总紧跟在 XmlDataLen （可加密）之后。 347 MessageEncoding 在报文的 “Encode” 域中使用的报文编码格式 （非 ASCII 编码） ，使用编码域时必需。 369 LastMsgSeqNumProcessed 最后处理报文序号（可加密） 。 1128 ApplVerID 使用 SP 标识方法标明应用版本，ApplVerID 用于一个特定报文的场景。 10 JR/T 0066.12019 域号/嵌套组件名 域名 必需域 备注 1129 CstmApplVerID 用于支持客户共同协商认可的功能。 1156 AppIExtID 组件 为历史跳跃信息重复组，记录报文经第三方发送的历史。 每次经第三方发送为一个跳跃， 仅当 OnBehalfOfCompID 使用时有效，主要用于跟踪报文的路径。注意：一些市场条例或者对手方可能要求追踪 hops 报文。 4.8.3 标准报文头在报文传输的应用 4.8.3.1 点对点传输 表3和表4展示了在两个市场参与方之间的单个点对点IMIX会话中如何使用SenderCompID、TargetCompID、SenderSubID、TargetSubID域。SenderSubID为SenderCompID的子机构，TargetSubID为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 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 DeliverTo 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 的发送时间 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）应是唯一的。因此，当使用OnBehalfOfCompID域（或DeliverToCompID域）进行寻址时，应在OnBehalfOfCompID域（或DeliverToCompID域）之后加上原值。这样，如果A发送报文到Q的ClOrdID为“123”，则Q将“A-123”作为ClOrdID的值发送到C，以确保唯一性。 报文转发场景示例见表6。 表6 报文转发场景示例 示例 条件/触发条件 预期行为 支持第三方机构编码 收到报文中，OnBehalfOfCompID 和DeliverToCompID 域值与会话配置中的OnBehalfOfCompID 和 DeliverToCompID 域值相同。 接收报文。 支持第三方机构编码 收到报文中，OnBehalfOfCompID 或DeliverToCompID 域值与会话配置中的OnBehalfOfCompID 和 DeliverToCompID 域值不同。 发送拒绝报文，描述无效的OnBehalfOfCompID 或 DeliverToCompID域值（sessionRejectReason=“CompID problem”)。 4.8.4 接收标准报文头场景示例 接收标准报文头场景见表7。 表7 接收标准报文头场景示例 示例 条件/触发条件 预期行为 接收标准报文头 接收预期的 MsgSeqNum 域值。 接收报文的 MsgSeqNum 域值。 MsgSeqNum 域值比预期高。 发起重发请求报文。 MsgSeqNum 域值比预期低并且 PossDupFlag域没有设置为 Y。 例外：SeqReset 被重置。 a）发送序号重设-重置报文，将对端下一个预期的报文序号重置成1； b）本方将下一个预期接收报文序号重置成12 JR/T 0066.12019 示例 条件/触发条件 预期行为 1。 接收到异常的报文a。 发送拒绝报文。 PossDupFlag 设置为 Y，OrigSendingTime 少于或等于 SendingTime， 并且 MsgSeqNum 域值低于预期。 注意： OrigSendingTime应早于SendingTime。 接收并处理该报文。 PossDupFlag 设置为 Y，OrigSendingTime 大于 SendingTime，并且 MsgSeqNum 与预期相同。 注意： OrigSendingTime 应早于 SendingTime除非该报文在同一秒被重新发送。 a）发送拒绝报文，描述错误的SendingTime（SessionRejectReason=“SendingTime accuracy problem”）； b）发出登出报文，等待登出报文响应，接收到登出报文响应后断开连接。 PossDupFlag 设置为 Y 且 OrigSendingTime值未被指定。 注意：响应重发请求报文时，由于报文的最初发送时间不是当前 SendingTime 值，因此应发送 OrigSendingTime，并且设置PossDupFlag=“Y” 。 发送拒绝报文，描述错误的OrigSendingTime（SessionRejectReason=“Required tag missing” ） 。 接收 BeginString 的值与会话指定值匹配。 接收报文的 BeginString 域值。 接收到的 BeginString 的值与会话指定值不匹配。 a）忽略该报文； b）设置下一个报文序号自增1； c）断开连接。 接收 SenderCompID 和 TargetCompID 的值与会话指定值匹配。 接收报文的SenderCompID和TargetCompID域值。 接收到的 SenderCompID 和 TargetCompID 值与会话指定值不匹配。 a）忽略该报文； b）断开连接。 接收到正确的 BodyLength 值。 接收报文中的BodyLength域。 接收到错误的 BodyLength 值。 重新计算BodyLength值，并赋值。 接收的 SendingTime 的值符合规定时间b。 接收报文的SendingTime域。 接收的 SendingTime 的值不符合规定时间。 a）发送拒绝报文，描述不准确的SendingTime（SessionRejectReason=“SendingTime accuracy problem”）； b）发送附有错误SenderCompID或SendingTime值的登出报文； c）（非必需）等待登出报文响应（注意：可能传来有错误的SendingTime值）。 接收到有效的MsgType的值 （数据字典定义） 。 接收报文的MsgType域。 接收到无效的 MsgType 的值（数据字典未定义） 。 a）忽略该报文； 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）非报文中的第三个域； 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 标准报文尾场景示例 接收标准报文尾场景示例见表9。 表9 接收标准报文尾场景示例 示例 条件/触发条件 预期行为 接收标准报文尾 有效的 CheckSum 域值。 接收报文。 无效的 CheckSum 域值。 a）考虑报文存在异常，忽略该报文； b）设置下一个报文序号自增1。 异常的报文。 a）考虑报文存在异常，忽略该报文； b）发送拒绝报文，其中Text域描述错误情况。 CheckSum 在报文的末尾域，域值的长度是 3 且以为结尾。 接收报文。 CheckSum 不在报文的末尾域，或域值的长度不是 3，或不以为结尾。 a）考虑报文存在异常，忽略该报文； b）设置下一个报文序号自增1。 5 会话传输 14 JR/T 0066.12019 5.1 会话机制 IMIX会话由一个或多个IMIX连接 （IMIX Connection） 组成。 IMIX连接由三部分组成： 登录 （logon） 、报文传输（message exchange）和登出（logout）。一个IMIX会话可多次登录。 5.2 报文序号 任何一条报文都被分配一个唯一的报文序号来加以标识。报文序号在每次会话过程中从1开始，在整个会话过程中连续递增，直到该会话过程全部结束。 5.3 心跳 在报文交换的空闲期间， 连接双方将在规定的时间间隔内发出心跳报文。 通过心跳报文可监测通讯连接的状态。 5.4 报文丢失 报文接收方应监测报文是否丢失并加以处理。 5.5 报文重复发送 报文发送方响应一个重发请求而重复发送报文时应在被重发报文内加上可能重复标志（PossDupFlag=Y），应重新计算校验和。报文接收方检查该报文，如果曾经接收过，则忽略报文；如果未曾收到过，则按正常步骤处理。 5.6 报文重新发送 报文发送方应设置可能重发标志（PossResend=Y），设置新的报文序号，重新计算校验和，重新发送报文。报文接收方收到该类报文后，应通过查询报文内的域（如订单编号等）来确定此前是否收到过该报文。 5.7 报文确认 报文接收方通过监测报文序号缺口来识别正常传送过程中的错误， IMIX应用层报文确认处理见JR/T 0066.22019。 6 会话管理 6.1 概述 连接双方各自维护一组连续的报文序号实现会话维持。会话过程分为三个部分：登录、报文交换、登出。 6.2 报文分类管理 报文分成会话层报文和应用层报文，根据附录A域字典中的域号35区分报文类型。 6.3 会话流程 6.3.1 数据交互时序图 会话流程数据交互时序图见图7。 15 JR/T 0066.12019 CLientServer1：发送35=A登录报文2：查找会话3：根据字典校验报文4：校验52域,登录状态,序列号等5：响应登录请求,发送35=A报文登录场景1：发送APP业务类型报文接收报文序号比本地存储期望接收序号高的场景2：序号太高要求重发,发送35=2报文3：重发要求重发的APP业务报文43=14：发送35=4重设序号报文5：重设本地要接收序号1：发送APP业务类型报文2：序号太低,设置本地接收和发送3：发送35=4,123=1序号重设报文4：设置本地接收和发送序号都从1开始接收报文序号比本地存储期望接收序号低的场景登出场景1：发送35=5登出报文2：修改登录状态,断开连接3：响应登出请求,发送35=5报文4：修改登录状态,断开连接* 图7 数据交互时序图 16 JR/T 0066.12019 6.3.2 会话流程状态 会话流程状态说明见表10。 表10 IMIX 会话流程状态 序号 状态 发起 方 接收 方 描述 1 断开-未登录 Y Y 当前处于断开状态，当日未进行连接尝试，将不会占用 MsgSeqNum报文序号（当日下一个连接的 MsgSeqNum 域值起始值为 1）。 2 监测到网络连接中断 Y Y 尝试连接时，监测到网络连接中断（如 TCP socket 关闭）。断开网络连接并关闭该会话。 3 等待连接 N