CN101931608A - 资源定位与发现基础协议消息的可靠性传输系统及方法 - Google Patents

Abstract

本发明提供一种资源定位与发现基础协议消息的可靠性传输系统及方法，该方法包括：请求消息的发送方发送请求消息后启动定时器T1，请求消息的接收方收到请求消息后向发来所述请求消息的发送方返回临时响应消息，收到所述临时响应消息的请求消息的发送方停止所述定时器T1，启动定时器T2；请求消息的接收方处理完成对请求消息的处理后向请求消息的发送方返回最终响应消息，所述请求消息的发送方收到最终响应消息后停止定时器T2，并向所述请求消息的接收方发送确认消息。采用本发明，可提高资源定位与发现基础协议消息的传递效率，同时能满足使其适用于电信网络的需求。

Description

资源定位与发现基础协议消息的可靠性传输系统及方法

技术领域

本发明涉及通讯领域，尤其是涉及一种资源定位与发现基础协议消息的可靠性传输系统及方法。

背景技术

P2P，英文Peer-to-Peer的缩写，中译为对等互联或点对点技术。P2P技术可以让用户可以直接连接到其他用户的计算机，进行文件共享与交换，同时P2P在深度搜索、分布计算、协同工作等方面也大有用途。

目前P2P在加强网络上人的交流、文件交换、分布式计算、服务共享等方面已经充分显示出了其强大的技术优势，但是P2P的应用主要还是集中在Internet应用中，在传统电信网络中尚未大规模应用。考虑到目前以及将来电信网络中，会话控制的主流是SIP(会话初始化)协议，因此，将P2P技术引入到电信网中去，必须能保证SIP协议在P2P网络中的应用。

基于以上考虑，IETF(互联网工程任务组)成立了P2PSIP工作组来研究这个问题，目前该组已经发布了其需求、架构、以及核心的基础协议：资源定位与发现基础协议(REsource LOcation And Discovery base protocol，简称RELOAD)，其基本架构如图1所示。

在本发明中，将P2PSIP工作组发布的需求、架构、以及协议，分别称为P2PSIP需求、P2PSIP架构、以及P2PSIP协议。

图1描述了P2PSIP工作组发布的P2PSIP网络基本架构。其中：

S101表示P2PSIP叠加网，它由各类担负不同角色的对等体(本发明中也称为节点)组成的一张逻辑网络；

S102为用户代理对等体Q，为P2PSIP叠加网中的基本组成部分，是能够给同一P2PSIP叠加网中其它节点提供存储和传送服务的节点；

S103为用户代理客户端C；

S104为重定向对等体R，除了具备普通用户代理对等体的能力外，还能为SIP用户代理提供SIP重定向能力；

S105为SIP用户代理A，为普通SIP终端；

S106为代理对等体P，除具备普通用户代理对等体的能力外，还能将SIP协议转换为P2PSIP协议；

S107为位于防火墙以及网络地址转换设备(Network Address Translation，简称NAT设备)后的用户代理对等体D；

S108为网络地址转换设备；

S109为位于防火墙与网络地址转换设备后的用户代理对等体E；

S110为用户代理对等体F；

S111为网关对等体G，为P2PSIP网络与PSTN等其他网络提供互通能力。

在图1中，可以看到在P2PSIP叠加网四周，列举了很多的P2PSIP对等体，有PSTN网关对等体“G”，三个用户代理对等体“D”，“E”和“F”，两个代理对等体“P”和“Q”，和一个重定向器对等体“R”。注意，因为它们都是P2PSIP对等体，每一个都负责存储一些P2PSIP叠加网的信息。

在左边，“D”和“E”对等体都在NAT设备的后面。它们都包含在P2PSIP叠加网内，并且参与存储信息。在P2PSIP叠加网之下，有一个传统的SIP用户代理“A”，它不是P2PSIP叠加网的一部分，既不直接作为一个对等体又不间接作为一个客户。它既不使用P2PSIP对等协议又不使用P2PSIP客户协议。它使用纯(未修改/扩展)SIP协议来与P2PSIP叠加网进行交互。“代理对等体”和“重定向对等体”能够作为一般SIP设备和P2PSIP叠加网之间的适配器。它们都接收标准的SIP请求消息，并且通过P2PSIP叠加网对等体协议获取P2PSIP叠加网中的路由信息，从而解析出下一跳，然后正确的处理SIP请求(转发或者重定向到下一跳)。代理操作是双向的——代理能够转发一个请求从一个普通的SIP设备到P2PSIP叠加网，或者从P2PSIP叠加网到一个普通的SIP设备。网关对等体与PSTN之间提供一个相似的适配过程。不同类型的对等体(重定向，用户代理，代理，网关)功能都是逻辑上的，单个实体能够支持一种，数种，或者所有功能。

作为P2PSIP工作组主要成果的RELOAD协议采用请求响应模式，一个正常事物包括一个请求消息与一个响应消息，也就是说一个正常请求有且仅有一个响应作为请求的回复。而RELOAD在实施过程中，往往基于UDP协议，所以RELOAD需要在应用层保证传输的可靠性，目前RELOAD采用的是基于请求消息的发送方重发的端到端的可靠性传输机制，如图2所示，描述了现有技术中RELOAD协议正常流程，其具体流程描述如下所示：

S201：对等体1发送请求消息给另一对等体，对等体2；

S202：对等体1发送请求消息后，启动重发定时器；

S203：对等体2处理完请求消息后，向对等体1回复响应消息；

S204：对等体1收到响应消息后，停止定时器，本次事物结束。

图3是现有技术中超时引发重传流程示意图，其具体流程描述如下：

S301：对等体1发送请求消息给另一对等体，对等体2；

S302：对等体1发送请求消息后，启动重发定时器；

S303：对等体1一直未能收到请求对应的响应消息，直到定时器超时，则触发请求消息重传流程；

S304：对等体1重传请求消息；

S305：对等体1启动再次启动定时器；

S306：对等体2处理完请求消息后，向对等体1回复响应消息；对等体1收到响应消息后，停止定时器，本次事物结束。

作为一项P2P技术，RELOAD消息自然可以通过一个或者多个中间节点(中继节点)进行转发，其通过中间节点转发流程如图4所示，具体描述如下：

S401：对等体1发送请求消息给中继对等体，即对等体2；

S402：对等体1发送请求后，启动重发定时器Time 1；

S403：对等体2收到请求消息后，查找下一跳目的地后，转发请求消息到对等体，即对等体3；

S404：对等体2转发请求后，启动重发定时器Time 2；

S405：对等体3处理完请求消息后，向对等体2回复响应消息；

S406：对等体2收到响应请求后，终止定时器Time 2；

S407：同时，对等体2将响应消息转发给对等体1；

S408：对等体1收到响应消息后，停止定时器Time 1，本次事物结束。

图4表述的为中间转发节点为有状态节点时的情形，当其为无状态时，中继节点将不启动重发定时器，即流程S404与S406不存在。

图5为现有技术中消息通过节点转发超时流程示意图，具体流程描述如下：

S501：对等体1发送请求消息给中继对等体，即对等体2；

S502：对等体1发送请求后，启动重发定时器Time 1；

S503：对等体2收到请求消息后，根据路由算法查找下一跳目的地(对等体3)后，转发请求消息到对等体3；

S504：同样对等体3根据路由算法查找下一跳对等体4，并试图将消息转发给对等体4，但却未能成功的将消息转发给对等体4；

S505：此时对等体1一直未能收到响应消息，所以当对等体1上定时器Timer1超时，启动重传机制，并重设定时器Timer 2；

S506：对等体1发送重传消息给对等体2；

S507：对等体2收到重传消息后，根据路由算法，将消息转发给下一跳的对等体，对等体3；

S508：对等体3转发消息给对等体4；

S509：对等体4转发消息给消息目的地对等体5；

S510：对等体5处理请求消息；

S511：对等体5处理完请求消息后，向对等体4回复响应消息；

S512：对等体4收到消息后，将根据请求响应消息对等原则，将响应消息转发给对等体3；

S513：同样，对等体3试图将消息转发给对等体2，但由于网络原因未能成功；

S514：此时对等体1上定时器Timer 2超时，由于尚未收到响应消息，则再次启动重传机制，重设定时器Timer 3；

S515：重传的请求消息经过对等体2、对等体3、对等体4的转发最终到达对等体5，其消息传递流程类似于流程S506～S509；

S516：对等体5将再次处理该请求消息；

S517：对等体5处理完成请求消息后，产生响应消息，响应消息依次经过对等体4、对等体3、对等体2后，最终倒带对等体1；

S518对等体1收到响应消息后，停止定时器Time 3，本次事物结束。

可以看到图5中的流程看到，请求消息与响应消息的传输都是依靠发送端(对等体1)的重发请求来保证其可靠性的，所以在图5流程中，只要出现一个消息的投递不成功，都需要发端进行重传，这相当于整个流程重新开始，这样的可靠性保证机制相对而言比较低效，设想如果消息需要经过多个中继，将会因为重发而产生大量的无效流量。

另外一点，现有的重发是保证端到端的可靠性，也就是说发起端发送请求消息后，启动的定时器将会等待该请求消息的响应消息，该等待时间中包含了请求消息在网络的传输时间(请求消息经过2个或者多个节点之间的传递)，对端处理请求消息、产生响应的时间，以及响应消息在网络的传输时间；由此要求等待时间会较长，目前IETF推荐的时间为5秒。并且也无法缩短该事件，如果缩短该时间，图5中流程将会出现对等体2、3、4、5尚未完成对请求、响应消息的处理与传递，对等体1就开始了重传消息，将进一步造成网络资源的浪费。所以如果传输过程中出现丢包现象，将会等待数秒后重传，造成定位一个P2P叠加网中的资源需要数秒以上的时间，这在目前P2PSIP应用的Internet环境中是可以被接受的。而在电信网络中，要求尽快定位到目标资源(如呼叫用户，要求尽快找到该用户或者表示该用户不可达)，因此目前P2P消息的可靠性传输机制是无法应用到电信网络中来的。

所以需要寻找一种新的RELOAD消息可靠性保障机制。

发明内容

本发明要解决的技术问题是提供一种RELOAD消息的可靠性传输系统及方法，可提高RELOAD消息的传递效率，同时能满足使其适用于电信网络的需求。

为了解决上述问题，本发明提供了一种资源定位与发现基础协议(RELOAD)消息的可靠性传输方法，包括：

请求消息的发送方发送请求消息后启动定时器T1，请求消息的接收方收到请求消息后向发来所述请求消息的发送方返回临时响应消息，收到所述临时响应消息的请求消息的发送方停止所述定时器T1，启动定时器T2；

请求消息的接收方处理完成对请求消息的处理后向请求消息的发送方返回最终响应消息，所述请求消息的发送方收到最终响应消息后停止定时器T2，并向所述请求消息的接收方发送确认消息。

进一步地，当请求消息的发送方与请求消息的接收方之间存在一个或多个转发节点时，收到请求消息的转发节点向前一节点返回临时响应消息，并将所述请求消息转发至下一节点，且在本地启动定时器T3；

所述转发节点收到下一节点发来的临时响应消息后停止所述定时器T3，启动定时器T4，并将收到的下一节点发来的最终响应消息转发至前一节点，并停止所述定时器T4；

所述前一节点为转发节点或请求消息的发送方，所述下一节点为转发节点或请求消息的接收方。

进一步地，当请求消息的发送方与请求消息的接收方之间存在一个或多个转发节点时，收到请求消息的转发节点将所述请求消息转发至下一节点；

所述转发节点收到下一节点发来的临时响应消息后将所述临时响应消息转发至前一节点，收到下一节点发来的最终响应消息后将所述最终响应消息转发至前一节点；

所述前一节点为转发节点或请求消息的发送方，所述下一节点为转发节点或请求消息的接收方。

进一步地，所述请求消息的发送方若在定时器T1超时前未收到临时响应消息则重发所述请求消息，并重新启动定时器T1，直到重发次数达到重发上限；

若重发次数达到重发上限，所述请求消息的发送方仍未在定时器T1超时前收到临时响应消息则本次传输失败。

进一步地，所述请求消息的发送方若在定时器T2超时前未收到最终响应消息，则本次传输失败。

进一步地，所述转发节点若在定时器T3超时前未收到临时响应消息则重新转发所述请求消息，并重新启动定时器T3，直到转发次数达到转发上限；

若转发次数达到转发上限，所述转发节点仍未在定时器T3超时前收到临时响应消息则本次传输失败，生成表明本次传输失败的最终响应消息发送至前一节点。

进一步地，若转发节点在定时器T4超时前未收到最终响应消息则本次传输失败，生成表明本次传输失败的最终响应消息发送至前一节点。

进一步地，所述转发节点收到下一节点发来的最终响应消息后停止本地的定时器T4，启动定时器T5，并向所述下一节点发送确认消息；当所述转发节点收到前一节点发来的确认消息后停止所述定时器T5。

进一步地，所述请求消息的接收方发送最终响应消息后启动定时器T6，当收到确认消息后停止定时器T6，若所述定时器T6超时前未收到确认消息则重新发送所述最终响应消息，并重新启动所述定时器T6，直到重发次数达到重发上限；

若重发次数达到重发上限，所述请求消息的接收方仍未在所述定时器T6超时前收到确认消息则本次传输失败。

进一步地，采用以下方式中的任一种或其组合区别临时响应消息与最终响应消息：

(1)以不同的错误码来区分临时响应消息与最终响应消息；

(2)以不同的响应消息体来区分临时响应消息与最终响应消息。

本发明还提供一种资源定位与发现基础协议(RELOAD)消息的可靠性传输系统，包括请求消息的发送方与请求消息的接收方；

所述请求消息的发送方用于发送请求消息后启动定时器T1；以及收到临时响应消息后停止所述定时器T1，启动定时器T2；还用于收到最终响应消息后停止定时器T2，并向请求消息的接收方发送确认消息；

所述请求消息的接收方用于收到请求消息后向发来所述请求消息的发送方返回临时响应消息，以及完成对请求消息的处理后向请求消息的发送方返回最终响应消息。

进一步地，所述系统还包括一个或多个转发节点；

所述转发节点用于收到请求消息后向前一节点返回临时响应消息，并将所述请求消息转发至下一节点，且在本地启动定时器T3；

所述转发节点还用于收到下一节点发来的临时响应消息后停止所述定时器T3，启动定时器T4，并将收到的下一节点发来的最终响应消息转发至前一节点，并停止所述定时器T4；

所述前一节点为转发节点或请求消息的发送方，所述下一节点为转发节点或请求消息的接收方。

进一步地，所述系统还包括一个或多个转发节点；

所述转发节点用于收到请求消息后将所述请求消息转发至下一节点；

所述转发节点还用于收到下一节点发来的临时响应消息后将所述临时响应消息转发至前一节点，收到下一节点发来的最终响应消息后将所述最终响应消息转发至前一节点；

所述前一节点为转发节点或请求消息的发送方，所述下一节点为转发节点或请求消息的接收方。

进一步地，所述请求消息的发送方还用于在定时器T1超时前未收到临时响应消息时重发所述请求消息，并重新启动定时器T1，直到重发次数达到重发上限；

若重发次数达到重发上限，所述请求消息的发送方仍未在定时器T1超时前收到临时响应消息则本次传输失败。

进一步地，所述转发节点还用于在定时器T3超时前未收到临时响应消息时重新转发所述请求消息，并重新启动定时器T3，直到转发次数达到转发上限；

所述转发节点还用于当转发次数达到转发上限，仍未在定时器T3超时前收到临时响应消息时，生成表明本次传输失败的最终响应消息发送至前一节点。

进一步地，所述转发节点还用于在定时器T4超时前未收到最终响应消息时，生成表明本次传输失败的最终响应消息发送至前一节点。

进一步地，所述转发节点还用于收到下一节点发来的最终响应消息后停止本地的定时器T4，启动定时器T5，并向所述下一节点发送确认消息；以及收到前一节点发来的确认消息后停止所述定时器T5。

进一步地，所述请求消息的接收方还用于发送最终响应消息后启动定时器T6，以及收到确认消息后停止定时器T6，还用于当所述定时器T6超时前未收到确认消息时重新发送所述最终响应消息，并重新启动所述定时器T6，直到重发次数达到重发上限；

若重发次数达到重发上限，所述请求消息的接收方仍未在所述定时器T6超时前收到确认消息则本次传输失败。

进一步地，所述系统采用以下方式中的任一种或其组合区别临时响应消息与最终响应消息：

(1)以不同的错误码来区分临时响应消息与最终响应消息；

(2)以不同的响应消息体来区分临时响应消息与最终响应消息。

采用本发明方案，不仅能用于端到端可靠性的保障，还能用于逐跳可靠性的保障，部署非常灵活。当使用本发明进行逐跳保障时，发送节点启动定时器只需要等待请求消息发送到下一跳，下一跳返回临时响应消息，等待时间大大小于现有技术中的定时器时长，而且即使发生重传，整个事物传递的时间也很短，可以应用于要求快速资源定位的电信服务中，从而解决了将RELOAD技术应用到电信领域的一个难题。

附图说明

图1是现有技术中P2PSIP网络架构示意图；

图2是现有技术中RELOAD协议正常流程示意图；

图3是现有技术中超时引发重传流程示意图；

图4是现有技术中消息通过节点转发流程示意图；

图5是现有技术中消息通过节点转发超时流程示意图；

图6是本发明系统结构示意图；

图7是本发明实施例一的流程示意图；

图8是本发明实施例二的流程示意图；

图9是本发明实施例三的流程示意图；

图10是本发明实施例四的流程示意图。

具体实施方式

本发明提供一种RELOAD消息的可靠性传输系统及方法，包括：请求消息的发送方发送请求消息后启动定时器T1，请求消息的接收方收到请求消息后向发来请求消息的发送方返回临时响应消息，收到临时响应消息的请求消息的发送方停止定时器T1，启动定时器T2；请求消息的接收方处理完成对请求消息的处理后向请求消息的发送方返回最终响应消息，请求消息的发送方收到最终响应消息后停止定时器T2，并向请求消息的接收方发送确认消息。

以下结合附图通过实施例具体描述本发明方案

本发明提供一种RELOAD消息的可靠性传输系统，如图6所示，该系统包括请求消息的发送方及请求消息的接收方，还可以包括一个或多个转发节点；

请求消息的发送方用于发送请求消息后启动定时器T1；以及收到临时响应消息后停止定时器T1，启动定时器T2；还用于收到最终响应消息后停止定时器T2，并向请求消息的接收方发送确认消息；

请求消息的发送方还用于在定时器T1超时前未收到临时响应消息时重发请求消息，并重新启动定时器T1，直到重发次数达到重发上限；若重发次数达到重发上限，请求消息的发送方仍未在定时器T1超时前收到临时响应消息则本次传输失败，请求消息的发送方若在定时器T2超时前未收到最终响应消息，则本次传输失败。

请求消息的接收方用于收到请求消息后向发来请求消息的发送方返回临时响应消息，以及完成对请求消息的处理后向请求消息的发送方返回最终响应消息。

请求消息的接收方还用于发送最终响应消息后启动定时器T6，以及收到确认消息后停止定时器T6，还用于当定时器T6超时前未收到确认消息时重新发送最终响应消息，并重新启动定时器T6，直到重发次数达到重发上限；若重发次数达到重发上限，请求消息的接收方仍未在定时器T6超时前收到确认消息则本次传输失败。

本系统中的转发节点可以是有状态的转发节点，也可以是无状态的转发节点；

(a)当转发节点为有状态的转发节点时：

转发节点用于收到请求消息后向前一节点返回临时响应消息，并将请求消息转发至下一节点，且在本地启动定时器T3；还用于收到下一节点发来的临时响应消息后停止定时器T3，启动定时器T4，并将收到的下一节点发来的最终响应消息转发至前一节点，以及停止定时器T4；

转发节点还用于在定时器T3超时前未收到临时响应消息时重新转发请求消息，并重新启动定时器T3，直到转发次数达到转发上限；

转发节点还用于当转发次数达到转发上限，仍未在定时器T3超时前收到临时响应消息时，生成表明本次传输失败的最终响应消息发送至前一节点。还用于在定时器T4超时前未收到最终响应消息时，生成表明本次传输失败的最终响应消息发送至前一节点。

转发节点还用于收到下一节点发来的最终响应消息后停止本地的定时器T4，启动定时器T5，并向下一节点发送确认消息；以及收到前一节点发来的确认消息后停止定时器T5。

(b)当转发节点为无状态的转发节点时：

转发节点用于收到请求消息后将请求消息转发至下一节点；

转发节点还用于收到下一节点发来的临时响应消息后将临时响应消息转发至前一节点，收到下一节点发来的最终响应消息后将最终响应消息转发至前一节点；

上述前一节点为转发节点或请求消息的发送方，上述下一节点为转发节点或请求消息的接收方。

所述系统采用以下方式中的任一种或其组合区别临时响应消息与最终响应消息：

(1)以不同的错误码来区分临时响应消息与最终响应消息；

(2)以不同的响应消息体来区分临时响应消息与最终响应消息。

本发明还提供一种RELOAD消息的可靠性传输方法，以下结合附图通过多个实施例详细说明本发明方法

实施例一

如图7是所示为本发明实施例一的流程示意图，该实施例中，对等体1为请求消息的发送方，对等体2为请求消息的接收方；对等体2收到请求消息后，立刻向对等体1返回临时响应消息，而对等体1收到临时响应消息后，不再进行请求消息的重发，图中具体流程步骤如下所示：

S701：对等体1发送请求消息给对等体2；

S702：对等体1发送请求消息后，立即启动定时器(标示为Timer 1a)；

步骤S701与702可同时执行。

S703：对等体2收到请求消息后，立即返回临时响应消息给对等体1；

S704：对等体1收到临时响应消息后，停止Timer 1a，同时启动Timer 1b；

S705：对等体2完成对请求消息的处理后，返回最终响应消息给对等体1；

S706：对等体2发送最终响应消息，并启动定时器(表示为Timer 2a)，用于接收确认消息；

S707：对等体1收到最终响应消息后，停止Timer 1b；

S708：对等体1向对等体2发送确认消息，表明本地已经收到最终响应消息；

S709：对等体2收到确认消息后，停止Timer 2a，本次事物结束。

图7中，有三个定时器，其中如果定时器1a超时，对等体1将启动重传机制，重传请求消息，直到重发次数达到重发上限，若重发次数达到重发上限仍未收到对等体2返回的临时响应消息，则本次事物失败；对等体2收到重传请求消息后，将需要对重传消息使用临时响应进行确认；如果Timer1b超时，表明本次事物失败；如果Timer 2a超时，对等体2将重传最终响应消息，并重新启动Timer 2a，对等体1收到重传的最终响应消息，将重新发送确认消息以示确认，若对等体2重发最终响应消息达到重发上限后，对等体2在Timer 2a超时前仍未收到确认消息则本次事物失败。

本实施例，对等体2上等待确认消息的Timer 2a可作为可选方案。

实施例二

如图8所示是本发明消息通过有状态节点转发实现逐跳可靠性的保证，该实施例中，对等体1为请求消息的发送方，对等体3为请求消息的接收方，对等体2为转发节点；其具体流程如下所示：

S801：对等体1发送请求消息给对等体2；

S802：对等体1发送请求消息后，立即启动定时器(标示为Timer 1a)；

S803：对等体2收到请求消息后，立即返回临时响应消息给对等体1；

S804：对等体1收到临时响应消息后，停止Timer 1a，同时启动Timer 1b；

S805：对等体2发送临时响应，并处理该请求消息，查找到该请求的下一跳，将请求转发给下一跳的目的地，即对等体3；

S806：对等体2转发请求消息后，立即启动定时器(标示为Timer 2a)；

S807：对等体3收到请求消息后，立即返回临时响应消息给对等体2；

S808：对等体2收到临时响应消息后，停止定时器Timer 2a，同时启动Timer 2b；

S809：对等体3完成对请求消息处理后，返回最终响应消息给对等体2；

S810：对等体3发送最终响应消息的同时，启动Timer 3a，用于等待确认消息；

S811：对等体2收到最终响应消息后，停止Timer 2b，同时启动Timer 2c；

S812：对等体2向对等体3发送确认消息，对等体3收到确认消息后，停止Timer 3a；

S813：同时对等体2转发最终响应消息给对等体1；

S814：对等体1收到最终响应消息后，停止Timer 1b；

S815：同时对等体1向对等体2返发送确认消息，对等体2收到确认消息后，停止Timer 2c，本次事物结束。

图8中对等体3启动Timer 3a以接收确认消息可作为可选方案，另外对等体2也可以不启动等待确认消息的Timer 2c，则在图中流程S811～S812，对等体2不启动定时器2c，不向对等体3发送确认消息，而在流程S815中，对等体2收到确认消息后，将确认消息转发给对等体3。

该实施例中，对等体2若在Timer 2a超时前未收到临时响应消息则重新转发请求消息，并重新启动Timer 2a，直到转发次数达到转发上限；若转发次数达到转发上限仍未在Timer 2a超时前收到临时响应消息则本次传输失败，生成表明本次传输失败的最终响应消息发送至对等体1。对等体2若在Timer 2b超时前未收到最终响应消息则本次传输失败，生成表明本次传输失败的最终响应消息发送至对等体1。

本实施例中，对等体3若在Timer 3a超时前未收到确认消息则重新发送最终响应消息，直到重发次数达到重发上限，并重新启动Timer 3a，若重发次数达到重发上限后，对等体3在Timer 3a超时前仍未收到确认消息则本次事物失败。若对等体2在Timer 2c超时前未收到确认消息则重新向对等体1发送最终响应消息，直到重发次数达到重发上限，并重新启动Timer 3a，若重发次数达到重发上限后，对等体2在Timer 2c超时前仍未收到确认消息则本次事物失败。

实施例三

如图9所示是本发明消息通过无状态节点转发流程示意图，本发明以此来实现端到端可靠性的保证，该实施例中，对等体1为请求消息的发送方，对等体3为请求消息的接收方，对等体2为转发节点；具体流程如下所示：

S901：对等体1发送请求消息给对等体2；

S902：对等体1发送请求消息后，立即启动定时器(标示为Timer 1a)；

S903：中继对等体2为无状态对等体，立即查找下一跳所在后，将请求消息转发到下一节点，即对等体3；

S904：对等体3收到请求消息后，立即返回临时响应消息给对等体2；

S905：对等体2将临时响应消息转发至对等体1；

S906：对等体1收到临时响应消息后，停止Timer 1a，同时启动Timer 1b；

S907：对等体3完成对请求消息处理后，返回最终响应消息给对等体2；

S908：同时对等体3启动Timer 3a，用于等待确认消息；

S909：对等体2转发最终响应消息给对等体1；

S910：对等体1收到最终响应消息后，停止Timer 1b；

S911：同时对等体1发送确认消息给对等体3，该确认消息可以根据需要由对等体2中转，也可以直接发送给对等体3，对等体3收到确认消息后，停止Timer 3a，本次事物结束。

本实施例中，对等体3若在Timer 3a超时前未收到确认消息则重新发送最终响应消息，直到重发次数达到重发上限，并重新启动Timer 3a，若重发次数达到重发上限后，对等体3在Timer 3a超时前仍未收到确认消息则本次事物失败。

实施例四

如图10所示，本实施例是对图5中所示的现有重传流程改进后的流程，其中，对等体1为请求消息的发送方，对等体5为请求消息的接收方，对等体2、对等体3及对等体4为转发节点；具体流程如下：

S1001：对等体1发送请求消息到对等体2，并接收对等体2返回的临时响应消息，此时对等体1将启动Timer 1b，用以等待最终响应消息；

S1002：对等体2根据叠加网络的路由算法，查找到下一跳的目的地对等体3，将请求消息转发给对等体3，并从对等体3接收临时响应消息；并在本地启动定时器；

S1003：对等体3根据路由算法计算得出下一节点为对等体4，向对等体4转发请求消息，该请求消息转发失败；

S1004：由于对等体3尚未收到临时响应消息，此时对等体3的Timer 3a超时，对等体3重传请求消息，重传请求消息成功，之后收到对等体4返回的临时响应消息；

S1005：对等体4根据路由算法，将消息传送到最终节点，即对等体5，并收到对等体5返回的临时响应消息；

S1006：对等体5处理请求消息；

S1007：对等体5处理完成请求消息后，向对等体4返回包含处理消息结果的最终响应消息，并收到对等体4返回的确认消息；

S1008：根据路由算法，对等体4将最终响应消息转发给对等体3，并收取从对等体3返回的确认消息；

S1009：对等体3根据路由算法，试图将最终响应消息转发给对等体2失败；

S1010：由于对等体3未能收到对等体2发送的确认消息，所以对等体3上的Timer 3c超时，对等体3向对等体2重传最终响应消息成功，并成功获取了对等体2返回的确认消息；

S1011：对等体2成功将最终响应消息转发给对等体1，并从对等体1获取的确认消息，事物结束。

对比图10与图5的流程，可以看出，在同样多的对等体间，发生两次重传，使用本发明后，仅仅需要在发送故障的对等体间，对故障消息进行重传，重传的波及面很小；并且对等体5上只需要对请求消息进行一次处理，屏蔽了现有技术中对等体5多次处理一个请求可能带来的麻烦，有利于简化基于RELOAD协议应用的实施。

并且由于Timer 3a、Timer 3c都可以设置为比较小的时间段，这样即使发生重传，整个事物传递的时间也很短，可以很快的实现网络中资源的定位，这样的特别非常适合在电信网络中应用。

以上各实施例中，为使临时响应消息区别于最终响应消息(包括成功响应消息与失败响应消息)，可以但不限于采用以下方式中的任一种或其组合：

(1)以不同的错误码来区分临时响应消息与最终响应消息；

(2)以不同的响应消息体来区分临时响应消息与最终响应消息，如临时响应消息采用简化消息格式。

Claims (19)

1.一种资源定位与发现基础协议(RELOAD)消息的可靠性传输方法，包括：

请求消息的发送方发送请求消息后启动定时器T1，请求消息的接收方收到请求消息后向发来所述请求消息的发送方返回临时响应消息，收到所述临时响应消息的请求消息的发送方停止所述定时器T1，启动定时器T2；

请求消息的接收方处理完成对请求消息的处理后向请求消息的发送方返回最终响应消息，所述请求消息的发送方收到最终响应消息后停止定时器T2，并向所述请求消息的接收方发送确认消息。

2.如权利要求1所述的方法，其特征在于：

当请求消息的发送方与请求消息的接收方之间存在一个或多个转发节点时，收到请求消息的转发节点向前一节点返回临时响应消息，并将所述请求消息转发至下一节点，且在本地启动定时器T3；

所述转发节点收到下一节点发来的临时响应消息后停止所述定时器T3，启动定时器T4，并将收到的下一节点发来的最终响应消息转发至前一节点，并停止所述定时器T4；

所述前一节点为转发节点或请求消息的发送方，所述下一节点为转发节点或请求消息的接收方。

3.如权利要求1所述的方法，其特征在于：

当请求消息的发送方与请求消息的接收方之间存在一个或多个转发节点时，收到请求消息的转发节点将所述请求消息转发至下一节点；

所述转发节点收到下一节点发来的临时响应消息后将所述临时响应消息转发至前一节点，收到下一节点发来的最终响应消息后将所述最终响应消息转发至前一节点；

所述前一节点为转发节点或请求消息的发送方，所述下一节点为转发节点或请求消息的接收方。

4.如权利要求1、2或3所述的方法，其特征在于：

所述请求消息的发送方若在定时器T1超时前未收到临时响应消息则重发所述请求消息，并重新启动定时器T1，直到重发次数达到重发上限；

若重发次数达到重发上限，所述请求消息的发送方仍未在定时器T1超时前收到临时响应消息则本次传输失败。

5.如权利要求1、2或3所述的方法，其特征在于：

所述请求消息的发送方若在定时器T2超时前未收到最终响应消息，则本次传输失败。

6.如权利要求2所述的方法，其特征在于：

所述转发节点若在定时器T3超时前未收到临时响应消息则重新转发所述请求消息，并重新启动定时器T3，直到转发次数达到转发上限；

若转发次数达到转发上限，所述转发节点仍未在定时器T3超时前收到临时响应消息则本次传输失败，生成表明本次传输失败的最终响应消息发送至前一节点。

7.如权利要求2所述的方法，其特征在于：

若转发节点在定时器T4超时前未收到最终响应消息则本次传输失败，生成表明本次传输失败的最终响应消息发送至前一节点。

8.如权利要求2所述的方法，其特征在于：

所述转发节点收到下一节点发来的最终响应消息后停止本地的定时器T4，启动定时器T5，并向所述下一节点发送确认消息；当所述转发节点收到前一节点发来的确认消息后停止所述定时器T5。

9.如权利要求1、2、3或8所述的方法，其特征在于：

所述请求消息的接收方发送最终响应消息后启动定时器T6，当收到确认消息后停止定时器T6，若所述定时器T6超时前未收到确认消息则重新发送所述最终响应消息，并重新启动所述定时器T6，直到重发次数达到重发上限；

若重发次数达到重发上限，所述请求消息的接收方仍未在所述定时器T6超时前收到确认消息则本次传输失败。

10.如权利要求1至3任一权利要求所述的方法，其特征在于：

采用以下方式中的任一种或其组合区别临时响应消息与最终响应消息：

(1)以不同的错误码来区分临时响应消息与最终响应消息；

(2)以不同的响应消息体来区分临时响应消息与最终响应消息。

11.一种资源定位与发现基础协议(RELOAD)消息的可靠性传输系统，包括请求消息的发送方与请求消息的接收方；其特征在于：

所述请求消息的发送方用于发送请求消息后启动定时器T1；以及收到临时响应消息后停止所述定时器T1，启动定时器T2；还用于收到最终响应消息后停止定时器T2，并向请求消息的接收方发送确认消息；

所述请求消息的接收方用于收到请求消息后向发来所述请求消息的发送方返回临时响应消息，以及完成对请求消息的处理后向请求消息的发送方返回最终响应消息。

12.如权利要求11所述的系统，其特征在于：

所述系统还包括一个或多个转发节点；

所述转发节点用于收到请求消息后向前一节点返回临时响应消息，并将所述请求消息转发至下一节点，且在本地启动定时器T3；

所述转发节点还用于收到下一节点发来的临时响应消息后停止所述定时器T3，启动定时器T4，并将收到的下一节点发来的最终响应消息转发至前一节点，并停止所述定时器T4；

所述前一节点为转发节点或请求消息的发送方，所述下一节点为转发节点或请求消息的接收方。

13.如权利要求11所述的系统，其特征在于：

所述系统还包括一个或多个转发节点；

所述转发节点用于收到请求消息后将所述请求消息转发至下一节点；

所述转发节点还用于收到下一节点发来的临时响应消息后将所述临时响应消息转发至前一节点，收到下一节点发来的最终响应消息后将所述最终响应消息转发至前一节点；

所述前一节点为转发节点或请求消息的发送方，所述下一节点为转发节点或请求消息的接收方。

14.如权利要求11、12或13所述的系统，其特征在于：

所述请求消息的发送方还用于在定时器T1超时前未收到临时响应消息时重发所述请求消息，并重新启动定时器T1，直到重发次数达到重发上限；

若重发次数达到重发上限，所述请求消息的发送方仍未在定时器T1超时前收到临时响应消息则本次传输失败。

15.如权利要求12所述的系统，其特征在于：

所述转发节点还用于在定时器T3超时前未收到临时响应消息时重新转发所述请求消息，并重新启动定时器T3，直到转发次数达到转发上限；

所述转发节点还用于当转发次数达到转发上限，仍未在定时器T3超时前收到临时响应消息时，生成表明本次传输失败的最终响应消息发送至前一节点。

16.如权利要求12所述的系统，其特征在于：

所述转发节点还用于在定时器T4超时前未收到最终响应消息时，生成表明本次传输失败的最终响应消息发送至前一节点。

17.如权利要求12所述的系统，其特征在于：

所述转发节点还用于收到下一节点发来的最终响应消息后停止本地的定时器T4，启动定时器T5，并向所述下一节点发送确认消息；以及收到前一节点发来的确认消息后停止所述定时器T5。

18.如权利要求11、12、13或17所述的系统，其特征在于：

所述请求消息的接收方还用于发送最终响应消息后启动定时器T6，以及收到确认消息后停止定时器T6，还用于当所述定时器T6超时前未收到确认消息时重新发送所述最终响应消息，并重新启动所述定时器T6，直到重发次数达到重发上限；

若重发次数达到重发上限，所述请求消息的接收方仍未在所述定时器T6超时前收到确认消息则本次传输失败。

19.如权利要求11至13任一权利要求所述的系统，其特征在于：

所述系统采用以下方式中的任一种或其组合区别临时响应消息与最终响应消息：

(1)以不同的错误码来区分临时响应消息与最终响应消息；

(2)以不同的响应消息体来区分临时响应消息与最终响应消息。

Images