IMIX Protocol会话机制

为了保证IMIX会话能够能够正常的开始和终止,保证IMIX消息在传送过程不会发生的消息丢失引起的消息序列缺口问题,以及其他一系列与IMIX消息传送相关的问题,IMIX定义了一套会话机制,该会话机制通过定义特殊的消息域以及会话消息实现了会话登录,会话注销,消息缺口填补,消息重复发送等传送场景的处理过程,这些都是IMIX协议为了保证消息正确传送提供的一种解决方案。如果具体的IMIX协议的实现者能够通过其他的技术或者机制保证消息的正确传送,就不用实现IMIX会话机制。

1      消息序号

任何一条消息都被分配一个唯一的消息序号来加以标识,消息序号在每次会话过程中从1 开始,在整个会话过程中连续递增,直到该会话过程全部结束。通过监视消息序号的连续性可识别交换中的消息缺口,并做出反应,使得连接双方数据同步。连接双方都明确确定相互独立的消息序号,参与连接的任何一方负责维护自己发送的消息序号,并监视接收的消息序号以保证消息缺口能被发现并加以处理。

2      心跳

在消息交换的空闲期间,连接双方将在规定的时间间隔内发出心跳消息。通过心跳消息可以监控通讯连接的状态,识别接收信息的序号缺口。心跳间隔时间由会话发起人在登录时,用登录中的心跳指令域(HeartBtInt)来加以确定。每次传送信息完毕之后,应立即重新设置心跳间隔计时器。心跳间隔时间应得到连接双方的确认,由登录会话发起方设定并得到登录接受方的确认回应。连接双方使用相同的心跳间隔时间。

3      缺口填补

本协议的消息传输模式是基于消息被完整传送的。但消息在传输过程中可能存在丢失,而消息发送方无法检测是否丢失了消息,因此消息接收方应负责检测消息的缺口并加以处理。有两种处理方法:(1)消息接收方发现缺口后向消息发送方请求发送缺口消息及其后的所有消息;(2)消息接收方发现缺口后,保存已收到消息,并向消息发送方请求重复发送缺口消息。

4      消息重复发送

在响应一个重发请求而重复发送消息时,或者不确定对方是否收到已发消息而重复发送该消息时,消息发送方须在被重发消息内加上可能重复标志(Possible Duplicate=Y)。如何处理该消息则由消息接收方处理。注意:当生成有此类可能重复发送的消息时,由于某些信息可能会改变,如原始时间、发送时间、正文长度、可能重复标志等,所以应重新计算校验和。

5      消息重新发送

消息重新发送,是基于应用层的可能重发消息。如发送的订单在相当长的时间内没有得到确认,或者怀疑其根本未曾被发送过,消息发送方可通过设置可能重新发送标志来重新发送(Possible Resend=Y)。消息接收方收到该类消息后,应通过查询消息内的域(如订单编号等)来确定此前是否收到过该消息。注意:此类消息应确定包含相同的正文数据,同样,由于某些信息可能会改变,所以应重新计算校验和。

6      消息确认

本协议的消息传输模式是基于消息被完整传送的;并且通过监测消息序号缺口以识别对正常传送过程中的错误。协议不支持对单个消息收发的确认,但大量的应用消息须在应用层作出明确的收发确认,如订单的确认。

7      会话连接

会话过程的数据交换可以这样描述:连接双方各有一组连续的消息序号随消息传送;交易期间可能多次断开并重新连接,其断开的原因可以是外因引起,也可以是连接双方根据系统而统一制定何时断开并重新连接。建议一次会话连接不超过24 小时;如需要保持24 小时以上的连接,则可发送一条含有序号重设标志的登录消息来建立新的起始消息序号。会话过程分为三个部分:登录、消息交换、注销。

7.1    登录

登录连接包含三个步骤:建立电信通讯连接、连接双方的确认/认证、消息传输同步的初始化。主要有以下几点:

7.1.1    连接

会话的发起方与会话接收方建立电信通讯连接。

7.1.2    认证

会话发起方发送登录消息(Logon),会话接收方认证发起方身份的合法性。登录消息应包括认证的必要数据,如用户名、密码等。如果会话发起方身份通过认证,则会话接收方发送一个登录消息作回应。如果认证失败,会话接收方则在发送一个包含失败说明的注销消息(Logout)后关闭连接。发送注销消息不是必需的,因为其占用了一个消息序号,而且在某些情况下可能会引起其他问题。登录成功后,会话发起方可在登录消息之后立即开始发送消息,但此时会话接收方可能并没有作好接收消息的准备;因此会话发起方应在收到接收方的登录消息确认之后,才认为会话连接建立完成。

建议:在登录后或者刚发送完测试请求消息(TestRequest)时延迟等待一段时间,双方再发送新的消息,使得连接双方能有效控制重发请求;否则可能会导致一方会针对对方的每一条新消息发出重发请求。

7.1.3    初始化

在身份通过认证之后,会话发起方和会话接收方应首先同步消息序号,然后才能相互发送新的信息。同步消息序号通过消息序号域(MsgSeqNum)来确定,将登录消息里的消息序号(MsgSeqNum)与内部监控的下一个预期的消息序号进行比较,就能发现消息的消息序号缺口。同样,会话发起方通过将会话接收方发送的登录消息里的消息序号(MsgSeqNum)与下一个预期的消息序号进行比较,也能发现消息的缺口。

7.2     消息交换

在以上初始化完成之后,可以开始进行信息交换。所有有效消息的格式将在“会话消息”和“应用消息”部分中详细叙述。

7.3     注销

会话的正常结束是通过连接双方互相发送注销消息(Logout)完成的。若结束时没有收到回送的注销消息(Logout),则把对方视作已注销。除此之外的其它方式的会话结束视为非正常,并应按错误来处理。

在发送注销消息(Logout)之前,应发送测试请求消息(TestRequest)以要求对方的心跳信息,这有助于保证不出现消息序号缺口。

在结束会话之前,注销消息(Logout)的发起方应该等待对方回送的注销消息(Logout),这样给注销消息的接收方一个填补缺口的机会。待重发请求的信息全部收到后,注销消息的接收方才可发送应答的注销消息(Logout)。如果注销消息的接收方在一定时间内没有答复,那么会话就可以立即中断。

注意:注销不影响任何订单的状况。所有有效的订单都可在注销(Logout)之后执行。

8      消息恢复

以下描述了有关恢复消息的具体方法。

当接收进来的消息序号与预期的消息序号不相符合时,需进行修正处理。但需要注意的是,如果接收进来的是序号重设消息(SeqReset-Reset),则不需要进行修正处理。因为此类消息的消息序号对随后的消息处理没有任何影响。如果接收的消息的消息序号比预期的消息序号小,而且没有设置可能重复标志(PossDupFlag),那么表明发生了严重的错误。因此建议强制结束会话,并开始进行人工干预。如果接收进来的消息序号比预期的大,那么表明有消息被遗漏,应通过发送重发请求申请填补缺口。

注意:以下段落中的请求人指的是提出重发请求的一方,重发人指的是回应重发请求的一方。当收到重发请求时,重发人可任选以下之一作出回应:

?  作为正常回应,重发人按顺序发送被请求的消息,这些消息的消息序号仍为原消息序号,并且将可能重复的标志(PossDupFlag)置位为“Y”。

?  作为正常回应,重发人发送序号重设-缺口填补(SeqReset-GapFill)消息,可能重复标志(PossDupFlag)置位为“Y”,以表示删除过时或多余的消息。

?  作为非正常回应,重发人发送序号重设-重设(SeqReset-Reset)消息,可能重复的标志(PossDupFlag)置位为“Y”,以强制消息序号同步。

在缺口填补过程中,某些会话管理消息不应被重新发送;取而代之的是一种特殊的序号重设-缺口填补消息(SeqReset-GapFill)。不应被重新发送的会话管理消息包括:登录、注销、重发请求、心跳、测试请求、序号重设-重设消息(SeqReset-Reset )和序号重设-缺口填补消息(SeqReset-GapFill)。由此,会话拒绝消息便成为了唯一可能被重新发送的会话消息。

会话过程中应监视接收到的消息,以便发现由于疏漏而被对方重新发送了的会话消息(设置了可能重复标志(PossDupFlag)的)。当收到这些消息以后,只须确认它们占有一个消息序号空间即可, 可以忽略消息中包含的对业务或应用的处理信息。

如果碰到多个连续的无需重发的会话消息, 建议只发送一个序号重设- 缺口填补消息(SeqReset-GapFill)。该序号重设-缺口填补消息的消息序号是下一个预期的消息序号。序号重设-缺口填补消息(SeqReset-GapFill)的新消息序号(NewSeqNo)为本连续会话消息段中最大消息序号+1。例如,在重新发送操作期间,有7 条连续的会话消息等待发送,他们以消息序号9 开始和以消息序号15 结束,此时只发送一个序号重设-缺口填补消息(SeqReset-GapFill)来代替那7 条消息,那么该序号重设-缺口填补消息(SeqReset-GapFill)的消息序号是9,这是因为要承接上条消息而保持消息序号的连续性;其中新消息序号(NewSeqNo)是16,这样使得对方知道下一消息发送时的消息序号。

建议:在缺口被填补完成之后,交换引擎应将无序的消息暂时保存为有序的排列并按顺序对它们进行处理,以防止出现对n->m,n->m+1,n->m+2,.的重发请求,否则会导致大量的可能重复(PossDupFlag=‘Y’)标记。

检验消息序号是否连续在会话过程管理中是必不可少的部分。不过,针对消息类型的不同,处理消息序号流的差异也有不同的处理。下列的表1列出了当接受到的消息序号大于预期消息序号时而应采取的措施。

注意:在任何情况下,除了序号重设-重设消息外,如果进来的消息序号比预期的消息序号小,而且可能重复标志(PossDupFlag)没有被设置,那么应立即终止会话过程。并应在结束会话之前,向对方发送带有解释正文的注销(Logout)消息。

消息类型 针对消息序号错误所采取的措施
登录 永远是连接双方发送的第一条消息,用于认证和确认连接。如果发现登录消息中有缺口,则应在回送登录确认消息之后立即发送重发请求
注销 如果发现有缺口,应发送重发请求消息以重新接收所有丢失的消息,然后再发送注销消息作为对注销请求的确认。注意严禁在有缺口情况下结束会话。并由注销的最初发起人负责结束会话,因此注销发起人有责任回应所有的重发请求
重发请求 首先处理完对方的重发请求,随后发送自己的重发请求以填补消息序号错误而发现的消息缺口。
序号重设-重设 可以忽略消息序号错误。因为在序号重设- 重设( SeqReset-Reset ) 消息中的新消息序号(NewSeqNo)强制为下一发送消息的消息序号。
序号重设-缺口填补 应立即向对方发送重发请求。但是,必需确保没有无意间跳过任何消息,这意味着缺口填补消息应按次序被接收到,如果次序不对,那么表示出现了非正常的情况
所有其它信息 执行正常的缺口填补。

1

 
建议使用IE8+浏览器, 1024x768分辨率