轻量级STEP会话层接口规范标准

("轻量级会话层接口规范（会话协议）本规范由上海证券交易所和深圳证券交易所联合发布文档说明文档名称轻量级会话层接口规范内容描述描述了轻量级的会话协议相关内容。修订历史日期版本修订说明创建α根据会员反馈意见进行修订：.增加了消息.修正了一些文字错误.将协议细分为兼容模式和精简模式，并列明协议兼容性矩阵及典型应用场景.为消息增补了会话状态字段.根据会员反馈意见增补了字段长度说明；.解释了什么叫做.根据正文的变更修订了附录α.修正了的说明文字，α中写的“”并不合乎当前协议的版本命名规则。.修正节中,的说明文字及的。.修正附录中关于消息检查的一个笔误除此之外，本版本和α内容并无不同。α.补充了一些字段的最大宽度说明.修正的说明，令缺省值为β.将版本名称从α重命名为β.将版本名称从β重命名为名词释义词汇缩写含义证券交易数据交换协议。金融信息交换协议。目录一、范围二、会话机制术语和定义会话层重传应用层重传和会话发起方和接受方消息序号心跳有序消息处理可能的消息重复传送可能的消息重新发送消息完整性混乱的消息()消息确认加密会话管理建立会话建立连接身份认证消息同步消息交换注销会话恢复登录消息处理重传请求消息处理序号重设消息处理三、消息定义消息结构消息头消息尾管理消息心跳消息（）登录消息（）测试请求消息（）重发请求消息（）会话拒绝消息（）序号重设消息（）注销消息（）四、数据字典数据类型会话层域定义附录（登录场景）正常登录场景一正常登录场景二正常登录场景三异常登录场景一异常登录场景二附录（注销场景）正常注销场景附录（处理重传请求场景）处理重传请求场景一处理重传请求场景二附录（处理心跳和测试请求）处理心跳和测试请求附录（处理会话拒绝）处理会话拒绝附录（计算校验和）计算校验和附录（状态转换参考图）会话协议状态转换参考图附录（实现参考）会话协议实现参考.消息.消息.消息.消息.消息.消息.消息.消息.应用消息轻量级会话协议接口规范一、范围本标准对会话层协议（即会话层协议版本）进行了裁剪和改造,确立了一个基于的轻量化会话层协议（记作：会话层协议），同时标准仍然可以保持和标准会话层协议的互操作性。本标准规定了会话层协议使用的会话机制、消息格式、安全与加密、数据完整性、扩展方式、消息定义、数据字典等内容。如无特别说明，本标准中提及的接收方、发送方等通信参与方均特指遵循会话层协议而实现的应用程序或模块。由于遵循本协议开发的程序或模块将可以同标准引擎进行正常通信，因此若通信的一方是标准的引擎，则除本文特别制订的少数额外约束外，其实现不受本文档约束。二、会话机制二.1术语和定义二.1.1会话层重传会话层重传是标准会话层协议所规定的一种重传机制，用来确保有序、无失地传输每一条会话层消息。在标准会话层协议中，会话层重传由消息接收方在识别出消息序号缺口之际主动发起，采取的方式是发送一条消息重传请求给到对方。会话协议在事实上取消了标准会话层协议的会话层重传，只对外仍然表现为标准的会话层，且可以和对端的标准会话层实现进行互操作。由于单个会话使用单个连接作为底层通信机制，因此在单个连接内部，每一条消息将被有序、无失地传输。属于同一会话的、前后相继的若干次连接之间，将可能存在会话层消息丢失，但收到的会话层消息将仍然具有有序接收的性质。由于在下会话层可能存在消息丢失，因此丢失的业务消息将只能通过应用层重传予以恢复。二.1.2应用层重传由于会话协议的会话层恢复机制仅仅是为了与标准会话协议兼容，不能作为真正的消息恢复机制使用。因此，必须通过应用层商定的重传机制予以恢复。应用层重传的具体机制不属于本文档规定的范畴，请参见具体的应用层数据接口规范。二.1.3和会话双方收发的每条消息都带有一个消息序号。参与通信的每一端都需要维护一对序号（，），表示下一个期望的入向消息序号，表示下一条出向消息将被赋予的序号。二.1.4会话发起方和接受方会话的建立需要一个发起方，需要一个接受方。发起方是先发出消息并希望对方响应以一个消息的一方，接受方则是等待发起方首先发出消息并响应以消息的一方。会话的发起方和接受方在会话建立后都可以双向地进行消息的发送和接收。不要将会话发起方（）、会话接受方（）同某条特定消息的发送方（）和接收方（）混为一谈类似于会话发起方和会话接受方，也定义有注销发起方和注销接受方、会话重置发起方和会话重置接受方的概念。标准协议原则上适用于各种不同的传输层协议（如），因此不可能根据等特定的传输层信息来区分哪些报文隶属于同一个会话，而且由于中并不为每个会话定义有所谓“会话号”标签，且不是全部报文都具有一类的标签，因此区分会话的唯一标识符只能是和的组合。标准协议中，单个引擎不能同时维护相同的两个会话。标准所推荐的做法是：在已存在一个合法会话时，若一方试图以同样的发起新的会话，对方将不发送任何消息就直接终止新发起的会话，原先已存在的会话不应受到影响。标准协议并未明确不同的引擎是否允许同时保有同样标识的会话。一般而言，同一台服务器上的同标识会话较易进行查重，针对不同服务器建立的同标识会话则较难实现查重，但也非无法做到。协议规定：在处理入向登录报文时，应利用和进行会话查重，之前已存在的同标识会话一定不受影响，但较晚收到的同标识会话请求可能被接受，但也可能被拒绝，协议不作限定。若请求被拒绝，则拒绝方式将遵循标准协议的约定，不回送消息，直接断开连接。会话发起方应当对这种情形做好准备。协议只允许单个会话同时通过单个连接进行全双工通信，因此在通过登录报文信息确定是否允许继续通信后，可以直接利用来区分报文所属会话，但对于从同一上收到的后续报文仍应检查其和是否和登录时一致。二.1.5消息序号所有的消息都由一个唯一的会话层消息序号(即消息头中的字段)进行标识。消息序号在会话开始时[一般]被初始化为，并在整个会话过程中连续递增1，直到该会话过程全部结束。通过监视消息序号的连续性，通信双方可以识别消息缺口并做出反应，并可在同一会话的前后多个连接间进行同步2。每次会话都会创建一套独立的入向及出向的序号序列，参与连接的任何一方都维护一套用于出向消息的序号序列()，同时也维护另一套独立的入向消息的序号序列()，用以监视接收的消息序号，以保证消息缺口的发现和处理。会话建立后，当协议实现者接收到的消息序号不等于预期接收的消息序号()时，需要考虑进行修正处理。这里有几种情况：1.如果入向消息序号<，且不属于前文脚注中注明的若干种情况之一时：表明发生了严重的错误，必须立即结束会话，并开始进行人工干预。2.如果入向消息序号<，且属于前文脚注中注明的若干种情况之一，不属于错误，应进行正常处理。3.如果入向消息序号>，那么表明有消息被遗漏。因为使用为传输协议，出现这种情况说明发生了严重异常错误，应立刻终止当前会话。1这个说法是针对通常情况而言的。在下述情况下，接收方收到的消息的MsgSeqNum也可能出现倒流：1)收到的消息是SeqReset-Reset消息且PossDupFlag=Y，此时MsgSeqNum应忽略，即使出现倒流也不是错误；2)除此以外，所收到消息的PossDupFlag是Y，且此类消息确实允许出现PossDupFlag=Y，表示这是会话层重传；3)通过LOGON消息进行会话序号重置时，收到的消息其MsgSeqNum一定是1，因此也可能出现倒流。2.LFIXT会话协议在事实上取消了标准FIX会话层协议的会话层重传，这里的同步只是为了兼容标准Fix会话机制，并不进行真实的消息同步。2二.1.6心跳在消息交换的空闲期间，连接双方将以规定的时间间隔产生心跳消息。通过心跳消息可以监控通讯连接的状态并识别出入向消息序号的缺口。心跳间隔时间由会话发起人通过登录消息的字段确定。在传送了任何消息(而不仅仅是心跳消息)之后，都应立即重置心跳间隔计时器。心跳间隔时间应该得到连接双方的确认，由会话发起人给出，并得到会话接受方的确认。连接双方应使用相同的心跳间隔时间。每个心跳消息都将占用一个消息序号。二.1.7有序消息处理会话协议采用连接作为底层通信机制，会话建立后，在同一个连接的延续期间，接收方在发现入向消息缺口时，说明发生了严重异常，建议接收方终止该会话并断开连接。如果接收方为会话的发起方，则应根据需要重建会话。二.1.8可能的消息重复传送本会话协议采用连接作为底层通信机制，会话双方在建立连接之后，通过消息进行序号协商，其后则是基于进行的连续通信，正常情况下，不应该出现前面消息丢失却收到后面消息的情形。所以，)在发现入向消息序号缺口时，会话协议的实现者不会发送重传请求，而是回送后直接断开连接，但)允许在入向消息中出现重传请求（比如基于标准引擎的通信对手方虽然收到前面的消息但自己没保存，并期望能按标准会话层协议通过重传请求取回），对此会话协议实现者将简单回送消息予以打发，）允许在入向消息中出现3的消息（比如基于标准引擎的通信对手方虽未收到本方发出的重传请求，但仅仅因为怀疑本方可能错过某些消息，而向本方发送这类的消息4）。二.1.9可能的消息重新发送在会话协议中，应用层重发的标志应在应用层协议中明确设置，而不应该体现在会话层消息的标志位上。由于互操作的对方必须遵从同样的应用层协议，因此会话协议将不会给出向消息打上任何标志。会话协议允许在入向消息头中出现标志，但将忽略该标志，直接将不附带该标志的消息交由应用层处理。3除了REJECT消息之外，其他管理消息理论上都不应被重发，而是通过发送带有同样消息序号的、带有PossDupFlag标志的SeqReset-GapFill消息对原消息进行替代。在此过程中，被替代的SeqReset-GapFill消息本身虽然仍然以同样的消息序号、带上同样被置位的PossDupFlag标志出现，也被FIX标准解释为“替代”而非“重发”。4.（PossDupFlag=Y）为Y的管理消息请参见具体的消息定义4二.1.10消息完整性消息数据内容的完整性可以用两种方式来验证：验证消息长度，及字符的简单校验和。消息长度被包括在字段中，可以通过清点消息之中跟在字段之后、直至并包括直接先于域号（””）出现的那个域界定符<>之间的字符来验证。校验和的验证方法是：从消息头中‘’中的‘’开始、直到并包括直接先于域号‘’出现的<>字符，将每个字符的二进制值加总后，将计算值的最低位同字段中的值进行比较。二.1.11混乱的消息()根据标准协议的附录，当至少出现以下情形之一时，一条消息被称为“混乱的”：()不是消息的第一个标签，或不以的形式出现。()不是消息的第二个标签，或未包含正确的字节计数()不是消息的第三个标签()不是最后的标签，或其取值不正确若()缺失，必须立刻终止连接，因为这表明出现了严重的应用错误，很可能只能通过修改软件来绕过。二.1.12消息确认由于会话层协议是基于乐观的消息传输模式，通过监视消息序号发现缺口，不支持对每个消息收发的确认。但大量消息收发的确认可在应用层定义。在应用层接受和拒绝是允许的。二.1.13加密会话层不对数据进行加密处理，会话双方可考虑使用通信层的加密机制。二.2会话管理会话协议采用连接作为底层通信机制。若会话协议的实现者作为会话的主动发起方，必须在每次新建连接之后通过置位序号重设标志()的消息来将起始消息序号重置回，因此，此时会话和连接是一一对应的。虽然会话协议可以被设计成底层使用两个独立的连接，每个连接都以单工模式工作，但由于在连接上实现全双工的通信并不困难且维护简单，因此会话协议规定：对于单个会话而言，同时只使用一个全双工的连接。若会话协议的实现者作为会话的接收方，由于该会话的发起方可能是标准的引擎，此时建立的会话可以跨越多个连接。在单次连接内部，每个会话都分为三个部分：建立会话、消息交换、终止会话。二.2.1建立会话建立会话包含三个步骤：建立连接（即为建立连接）、身份认证、消息同步。二.2.1.1建立连接会话的发起方与接受方建立连接。会话协议的实现者在连接建立后，应当总是初始化,。二.2.1.2身份认证1.会话发起方发送登录消息（），接受方认证发起方身份的合法性。2.如果发起方身份通过认证，则接受方发送一个登录消息作回应。3.如果认证失败，会话接受方则在可选地发送一个含失败说明的注销消息（）后关闭连接。发送注销消息并非是必须的，因为这样做会消耗一个序号，在某些情况下可能会引起其他问题5。4.会话发起方必须等待来自接受方的确认消息，方可向接受方发送其他消息。否则，接受方可能尚未准备好接收它们。5.在发起方被认证后，接受方将立即回应一个确认消息。发起方将把从接受方返回的消息作为“一个会话已经建立”的确认。二.2.1.3消息同步会话协议并不提供真正的会话层重传机制，因此会话协议的实现者作为会话的发起方，可通过会话重置消息（即的消息）将会话双方的消息序号重置，来完成会话层消息同步。会话协议的实现者作为会话接受方，可以利用消息中的来完成会话层消息同步。这种方式提供了对标准会话协议的消息同步的兼容，具体机制参见“登录消息处理”一节。二.2.2消息交换在建立会话之后，会话双方可以开始进行正常的消息交换。交换的消息包括“管理消息”和“应用消息”，本规范仅对管理消息进行描述。应用消息请参见具体的数据接口规范。二.2.3注销会话会话的正常结束是通过连接双方互相发送注销消息（），注销时不需要进行消息缺口检查。若结束时没有收到回送的注销消息（），则把对方视作已注销。除此之外的其它方式的会话结束视为非正常，并应按错误来处理。在结束会话之前，注销消息（）的发起方应该等待对方回送的注销消息（）。如果5这个问题和标准FIX引擎对于报文所属会话的认定方式有关,单在LFIXT引擎方面则并无不妥。接收方在一定时间内没有答复，那么会话就可以立即中断6。二.3恢复会话协议的会话层恢复机制是为了与标准会话协议兼容，不能作为真正的消息恢复机制使用，会话对端应通过应用层的消息恢复机制来获得缺失的数据。会话协议的实现者只在建立会话阶段存在消息序号同步，在会话持续期间不提供真正的消息恢复，而是简单地通过回应消息来打发消息重传请求。二.3.1登录消息处理会话协议的实现者作为会话接收方,只需将本方设置为发起方消息的，设置为发起方消息中的()即可。会话接收方不需要检查任何缺口，会话接收方也不会向发起方请求重传任何消息。如果发送方没有提供字段，则设置为.二.3.2重传请求消息处理作为会话协议的实现者不会主动发送重传请求，但可能收到标准的会话协议实现者发送的重传请求。当会话协议的实现者收到重传请求时，会使用消息重置发送方序号而不会提供历史消息的重传。二.3.3序号重设消息处理会话协议的实现者收到序号重设消息时，会根据序号重设消息中的来重置本方。6注销不影响任何订单的状况。所有有效的订单都可在注销（Logout）之后执行。三、消息定义三.1消息结构每一条消息都由消息头、消息体、消息尾组成。消息总是由标准消息头开始，标准消息尾结束。三.1.1消息头会话双方所有交换的消息具有如下标准的消息头。每一个消息都由一个标准消息头开始。消息头定义了消息的类型，长度，目的地，顺序号，起始点和时间等数据域，均不加密传输。其中有两个域用于消息重发。当作为会话级事件的结果而重复传送消息时，被设置为，发送时沿用原来的消息序号；当[应用级]重新发送消息时，使用新的消息序号，并将设置为。接收者应按以下方法处理上述消息：：如果以前曾经收到过带有该消息序号的某条消息，则忽略本消息，如果不是，则按正常步骤处理。：不附带本标志地将消息传递给应用层，由其确定此前是否收到该消息域名必须字段描述起始串(总是不加密，必须是消息的第一个域)消息体长度(总是不加密，必须是消息的第二个域)消息类型(总是不加密，必须是消息的第三个域)发送方代码字符串(总是不加密)接收方代码字符串(总是不加密)消息序号，整数类型会话层可能重传标志，重复传送时，作此标记应用层可能重发标志。会话层协议的实现者不会在出向消息中主动设置本字段，对于入向消息中出现的本字段将简单忽略发送时间，类型消息中编码域的字符编码类型，缺省为三.1.2消息尾会话双方所有交换的消息具有如下标准的消息尾。每一个消息（管理或应用消息）都用一个消息尾终止。消息尾可用于分隔多个消息，包含有位数的校验和值。域名必须字段描述校验和，总是消息的最末域，总是不加密三.2管理消息会话协议支持标准会话协议的所有管理消息，但不会主动发送所有管理消息。会话协议分两种模式：精简模式和兼容模式，各自有不同的使用范围。已知通信对手方为会话协议实现者时，可以采用精简模式，此时只需要支持如下消息的接收和发送处理。此时由于本方不会主动发送，因此根据协议也不会触发对方回应，因此不需要处理入向的消息：管理消息类型来自对方本方发送是是是是是是是是表1精简模式：仅和实现者通信时当需要和基于标准引擎的对手方进行通信时，必须采用兼容模式。此时会话协议实现者需要支持所有管理消息的接收，但仍然不需要支持所有管理消息的发送。兼容模式和精简模式主要的区别只在于前者需要处理更多的入向管理消息。管理消息类型来自对方本方发送是是是是是否是否是是是是是否是是表2兼容模式：和标准会话协议实现者通信时一般而言，交易所端的引擎应采用兼容模式以取得最大程度的协议兼容性。在已知交易所端采用兼容模式协议的前提下，券商端可以选用精简模式的协议，从而用最小的代价实现交易所接入，自然也可以考虑采用兼容模式甚至是标准会话层协议完成交易所接入。必须注意：精简模式的协议实现简便，但不具备和标准协议互通的能力，券商必须全面衡量各系统的总体成本以确定实际使用的协议。标准协议兼容模式精简模式标准协议√√×兼容模式√√精简模式√表3协议兼容性矩阵三.2.1心跳消息（）会话双方使用消息来检测当前使用的连接的状态，因此当一方处于数据发送空闲期时，需要定时发送消息以供检测链接的健康度。接收方如果在两倍的（[]＋[合理传输时间]）内没有收到来自对方的心跳消息，就认为连接失败，此时可以不发送消息，立即关闭连接。会话协议不会主动发送消息，但会话协议的实现者，为了与标准会话协议的兼容，如果收到了请求，会按标准会话协议向发送方返回心跳响应。如果上层应用定义有应用层心跳信息，并以不低于的间隔主动发送，则在事实上使得会话层心跳消息的发送条件永远得不到满足。在这种情况下，一方即使只收到应用层心跳消息，永远也收不到来自对方的会话层心跳消息，也不构成对本协议的违反。域名必须字段描述字符串。如是对响应而发送的心跳消息，则应包含本域。本域的内容直接来自于触发本心跳消息的消息的内容三.2.2登录消息（）登录消息应是请求建立一个会话的应用所发送的第一个消息。()域用来声明产生心跳的超时间隔（连接双方使用相同的值）。连接双方事先约定取值，由登录发起方产生，并得到登录接受方的确认响应。当收到登录消息时，会话接受方将验证发起方身份的合法性，并且发出登录消息作为连接请求已被接受的确认。同样，确认的登录消息也可以被发起方用以验证连接是与正确的对方建立的。会话接受方应在收到登录消息之后，立即作好开始消息处理的准备。本标准规定：必须等到返回的登录消息收到之后才实施正常的消息交换。会话协议实现着若作为会话发起方，其发送的消息需将设置为、设置为、设置为。标准引擎若要向协议实现者发起会话，且选择采用()来实现序号同步，必须在消息中将该字段填写为标准引擎已保存的入向消息的最大序号。比如标准引擎保存了入向消息，没有保存入向消息和，但保存了入向消息，此时应该填写此字段为，而非。这一点在协议中并未明确规定，故本文档对此予以特别限定。域名必须字段描述加密方法始终为，即不加密心跳间隔，单位是秒。双方必须用同一个值双方序号重设回的标志，布尔型接收方期望得到的下一条消息序号，可选。若不填写，认为取值为用户名密码本次会话中使用的消息的缺省版本。本次会话中使用的消息[在基础上]的缺省扩展包。本次会话中，消息的缺省自定义应用版本。本标签是对的进一步约束。本字段必须填写交易所发布的数据接口规范版本。如果接入方不提供该字段，接收方将不会允许接入方接入，并会通过消息终止该会话。三.2.3测试请求消息（）测试请求消息能强制对方发出心跳消息。会话协议不会主动发送该消息。测试请求消息的作用是检查对方消息序号和检查通信线路的状况。对方用带有测试请求标识符（）的心跳作应答。协议的实现方不会主动发送任何消息域名必须注释测试请求标识符三.2.4重发请求消息（）重发请求消息由接收方发出，目的是向发送方申请某些消息重复发送。会话协议不会主动发送该消息。重发请求消息有以下几种表示方式：\uf06c请求重发一条消息：\uf06c请求重发某个范围内的消息：该范围中的第条消息序号，该范围中的最后一条消息序号。注意请求重发一条消息只是本形式的特例。\uf06c请求重发某一特定消息之后的所有的消息：该范围中的第条消息，（代表无穷大）会话协议的实现者作为本消息的接收方时，只会通过消息响应标准会话协议实现者发送的重传请求消息。域名必须注释起始消息序号结束消息序号三.2.5会话拒绝消息（）当接收方收到一条消息，由于违反了会话层规则而不能适当地处理该消息时，应该发出（拒绝）消息。发出消息可能是合适的一个例子是：收到了一条成功经过解码、校验和检查及检查的消息，但该消息带有不合法的基本数据（比如：）。规则要求：只要可能，消息应尽可能被转发给交易程序并通过业务层拒绝（而非会话层的消息）来响应。若收到一条满足会话层规则的应用层消息，它必须在业务消息的层面被处理。若此处理过程发现了规则的违反，则应当产生一条业务层拒绝消息。许多业务层消息有特有的“拒绝”消息，应该使用这些消息。全部其他情况都可以通过“业务消息拒绝消息”进行拒绝。注意，即使收到了业务消息，且满足会话层规则，但当此消息不能被送达业务层处理系统的时候，也应该发送一条“应用此刻不存在”的“业务消息拒绝”消息。被拒绝的消息应该被记录日志，且入向序号应该增加。和标准会话协议不同之处在于：在会话协议中，如果收到的消息是混乱的()，或者说：不能被解析或不能通过数据完整性检查时，应当记录日志后回送消息并立刻断开连接（在标准会话协议中建议忽略并丢弃本消息，以期望后续收到的正确格式的消息能触发一个消息缺口，从而能通过重传请求再度拿回这条混乱的消息）。同时也需要注意：这并非会话层消息的使用场景。产生和收到消息，意味着出现了严重错误，可能发送方或接收方的应用存在逻辑错误。如果发送方应用选择重新发送被拒绝的消息，应当使用新的消息序号并设置。因为的语义是可能的应用层重发，因此这里被重新发送的一定是指应用层消息而非管理消息。只要有可能，强烈推荐在本消息的字段中描述引起错误的原因。当收到消息本身时，建议记录日志，然后调整入向序号。域名必需说明关联消息的序号，即被拒绝消息(对方发送且己方收到)的序号。相关错误消息中，出现错误的域号相关错误消息的会话拒绝原因编号文本，可解释拒绝的原因会话拒绝原因()无效域号该消息中必须的域丢失该消息中出现未曾定义的域未定义的域号声明了域，但未赋值此域的值错误（范围溢出）取值格式错误解密错误签名错误错误发送时间精度错误无效的验证错误域多次出现（非重复组）有序的域出现次序错误重复组中，域次序错误重复组中，错误非数据域中，出现域界定符<>其他。注意可能存在其他的会话层规则违反，此时，“会话拒绝原因”可以被使用，进一步的信息应当包括在字段中。表4会话拒绝场景三.2.6序号重设消息（）序号重设消息由发送方发出，用于告知接收方下一个消息的消息序号。序号重设消息有两种模式：序号重设缺口填补（）；序号重设重设（）。在会话协议中，只使用消息回应消息，此消息的按标准协议规定可以任意填写且接收方不会检查，在中规定固定填写，其中的则建议填写为{消息的字段值，本方值}。序号重设只能增加消息序号。如果收到的序号重设消息试图使下一个预期的消息序号变小，那么此消息应被拒绝接受，并被视作为严重错误。在会话协议中，虽然不会主动发起重传请求，但仍然有可能收到标准协议的对手方主动发出的类消息。当收到的序号重设消息为消息时，必须确保必须大于等于消息本身的且不允许>，此时本方保持不变；否则，被视为严重错误。当收到消息时，则需要忽略的检查，同时令本方。域名必须注释缺口填补标志。布尔型。“”表明是模式；“”或不存在本域，表明是模式。新消息序号三.2.7注销消息（）注销消息是发起或确认会话终止的消息。未经注销消息的交换而断开连接，一律视为非正常的断开。在最后终止会话之前，注销的发起人应该等待连接对方确认注销消息。如果连接对方没有在适当的时间间隔里作回应，那么会话就可以终止。注销发起人在发送注销消息之后不应发送任何消息，除非接收到连接对方发出的重传请求消息。何时发送，何时直接断开一般而言，在关闭连接前推荐的做法是回送一条消息以利于对端诊断连接断开的原因。但此处可有一些例外：.若收到的登录报文中，,或者会话发起方的地址不合法，推荐做法是会话立即终止，不发送任何消息。原因是此种登录尝试很可能属于未被授权的系统入侵行为，因此不应当回送消息以泄露版本、合法、等信息。.在标准协议中，在收到登录请求时若在同一个引擎若已存在一个合法的相同的会话，则标准引擎将直接断开后来的登录请求所欲发起的会话。由于任何时刻总是存在网络中断的可能，因此协议的任何参与方都应该对于没有收到对方的消息但底层连接却已关闭的情况做好准备。在断开连接前回送消息是推荐行为，但非必须。在此简要总结一下：对于收到报文中的各类异常接收方通常处理的原则。1.通信异常潜在的恶意攻击推荐处理方式是直接断开连接。由于在任何情况下通信参与者都必须能够处理连接的中断，因此这也是缺省处理办法。对于同一个连接上，第一个收到的报文不是正确的报文，或者在已经成功的连接上又收到一个普通的消息，视作恶意攻击，直接断开。2.混乱的报文、入向消息序号出现缺口推荐处理方式是回送消息，然后断开连接3.报文不混乱，但不满足会话层规则推荐处理方式是发送拒绝此消息，会话继续4.报文不混乱，满足会话层规则交给应用层去处理。如果应用层发现报文违反了应用层规则，回送应用层拒绝消息会话继续域名必须字段描述时的会话状态。根据协议有如下取值：会话活跃会话口令已更改将过期的会话口令新会话口令不符合规范会话退登完成不合法的用户名或口令账户锁定当前时间不允许登录口令过期收到的()太小收到的()太大.及以上的数字可供用户在双边认可的情况下自定义文本。注销原因的进一步补充说明。四、数据字典四.1数据类型数据类型类型定义说明消息序号正整数‘’,‘’长度表示字节为单位的数据长度，非负数时间戳，注意，协议允许使用，,,,,,（秒）,或(毫秒)，,,,,,（秒）,（毫秒）之中的任何一种格式本地时间戳(毫秒)，,,,,,（秒）,（毫秒）重复数表示重复组的项数，正数注：除非特别声明，浮点数类型均有正负，类型定义()中，表示整数与小数总计位数的最大值，不包括小数点，表示固定的小数位数。类型定义中，表示字符串的最大长度四.2会话层域定义域名类型说明起始消息序号起始串固定为消息体长度校验和不加密，必须是最后一个域校验算法参见协议结束消息序号消息序号，由开始消息类型新消息序号指示该消息序号的消息可能重复发送，取值：:可能重复:首次发送发送方代码消息发送时间，类型接收方代码文本可能重发标志指示该消息可能发送过（使用不同的消息序号），取值：:可能重发:首次发送加密方法:即不加密心跳监测的时间间隔为系统设定值,以秒为单位测试请求标识符序号重设标志缺口填补标志用于序号重设消息，指示是否填补缺口，取值：:序号重设缺口填补消息，消息序号域有效或不存在序号重设重设消息，消息序号域无效消息中编码域的字符编码类型缺省是相关错误消息中，出现错误的域号相关错误消息的会话拒绝原因编号，无符号整数最大消息长度，单条消息的最大字节数。该字段暂未启用用户名密码接收方期望得到的下一条消息序号本次会话中使用的消息的缺省版本。若取值为''，意思是''本次会话中使用的消息[在基础上]的缺省扩展包。若取值''，意思是''本次会话中，消息的缺省自定义应用版本。本标签是对的进一步约束。本字段填写交易所发布的数据协议版本。建议的格式是：版本号市场代码市场内部唯一的协议版本号。市场代码是时，代表上海证券交易所；是时，代表深圳证券交易所。市场内部唯一的协议版本号由各市场自行分配。本字段填写退登时的会话状态附录A（登录场景）正常登录场景一作为登录发起方——，作为登录接受方——，日间正常登录。场景开始时，连接刚建立时，的,，的,。ClientServer建立TCP连接LOGONTag34/MsgSeqNum=1Tag141/ResetSeqNumFlag=YTag789/NextExpectedMsgSeqNum=1LOGONTag34/MsgSeqNum=1Tag141/ResetSeqNumFlag=YTag789/NextExpectedMsgSeqNum=2LFIX会话成功建立图A.1正常登录场景一会话建立后，的,，的,。正常登录场景二标准作为登录发起方——，作为登录接受方——，日间非首次正常登录，且不设置，设置为其在前一次连接断开时的。场景开始时，连接刚建立后，的,，的,。在此之前，曾经向发送过为，的业务消息，但因为通信故障，没有收到，所以端保存的仍然是，而非。ClientServer建立TCP连接LOGONTag34/MsgSeqNum=100Tag141/ResetSeqNumFlag=NTag789/NextExpectedMsgSeqNum=189LOGONTag34/MsgSeqNum=189Tag141/ResetSeqNumFlag=NTag789/NextExpectedMsgSeqNum=101FIX会话成功建立NxtIn=101NxtOut=189NxtIn=1NxtOut=1图A.2正常登录场景二会话建立后，的,，的,。注意两次连接上发送给的的消息并不相同，但因为没有保存之前收到的的业务消息，所以第二次收到的应答消息也不会发现存在不一致。正常登录场景三为了说明在标准协议中，相关的自动缺口填补的原理，撰写此场景。本场景中，通信双方都遵循标准协议。在场景开始的时候，的是，是；由于和之间出现了网络中断，因此只收到了序号为（含）以前的来自的消息,其是，是。收到的来自的登录消息中，是，但端内部下一个发送的应该是消息，必须使用新的序号。但端也知道端出现了消息缺口，且根据协议不会为此缺口发送消息，而是需要端主动推送缺口部分的消息。因此端马上重复传送业务消息，业务消息，并用消息替代消息——消息，之后就可以开始正常传送业务消息。ClientServerLogonLogonTag34/MsgSeqNum=200Tag789/NextExpectedMsgSeqNum=248Tag34/MsgSeqNum=250Tag789/NextExpectedMsgSeqNum=201重传应用消息248NxtOut=200NxtIn=248NxtOut=201NxtIn=248NxtOut=250NxtIn=200NxtOut=250NxtIn=201NxtOut=251NxtIn=201NxtOut=201NxtIn=251Server发现自己发送了消息250，但Client最多只知道消息247，因此必须主动填补缺口Tag34/MsgSeqNum=248Tag43/PossDupFlag=Y重传应用消息249Tag34/MsgSeqNum=249Tag43/PossDupFlag=YSeqReset-GapFill替代LogonTag34/MsgSeqNum=250Tag123/GapFillFlag=Y应用消息251Tag34/MsgSeqNum=251Tag43/PossDupFlag=NNxtOut=201NxtIn=252NxtOut=201NxtIn=251NxtOut=252NxtIn=201图A.3正常登录场景三异常登录场景一标准作为登录发起方——，作为登录接受方——，日间非首次正常登录，且不设置，也没有设置为其在前一次连接断开时的。场景开始时，连接刚建立后，的,，的,。ClientServer建立TCP连接LOGONTag34/MsgSeqNum=100Tag141/ResetSeqNumFlag=NLOGONTag34/MsgSeqNum=1Tag141/ResetSeqNumFlag=NTag789/NextExpectedMsgSeqNum=101NxtIn=101NxtOut=1NxtIn=189NxtOut=100NxtIn=189NxtOut=101MsgSeqNum意味着严重错误消息的最基本处理：清接收超时计时器和计数3.消息收到消息类型：引擎可以发出：否消息的最基本校验：不能是<>意味着严重错误消息的最基本处理：回送消息，清发送超时计时器和计数，清发送超时计时器，4.消息收到消息类型：引擎可以发出：否消息的最基本校验：不能是<>意味着严重错误如果>必须保证<<如果必须保证<消息的最基本处理：发送作为应答，其固定是，设置为。发送,保持不变5.消息收到消息类型：引擎可以发出：是消息的最基本校验：必须是不需要校验,但必须>接收方的才可以，否则是严重错误消息的最基本处理：6.消息收到消息类型：引擎可以发出：否消息的最基本校验：必须是必须大于等于消息本身的，否则是严重错误。>是一个严重错误消息的最基本处理：保持不变7.消息收到消息类型：引擎可以发出：是消息的最基本校验：若<且，意味着严重错误>意味着严重错误消息的最基本处理：记录日志8.消息收到消息类型：引擎可以发出：是消息的最基本校验：不能是<意味着严重错误消息的最基本处理：如果在本消息校验过程中发现错误：如果本方是过程的发起方则马上断开连接否则在回应的消息中告知对方校验错误发送后立刻断开连接否则如果本方是过程的发起方可以马上断开连接。否则，发送正常消息后立即断开连接9.应用消息收到消息类型：应用消息引擎可以发出：是消息的最基本校验：若<且，意味着严重错误若>，意味着严重错误消息的最基本处理：",)