报文传输方法及设备的制作方法

文档序号:7804242阅读:224来源:国知局
报文传输方法及设备的制作方法
【专利摘要】本发明公开了报文传输方法及设备,用以实现报文的保序通信。所述方法包括:确定发送者应用需要发送给接收者应用的报文;确定发送者应用与接收者应用之间的关联关系,其中,关联关系包括:发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系;按照报文发往所述接收者应用的发送顺序确定所述报文对应的报文序号,并利用所述报文序号对所述报文进行封装后存储到所述关联关系对应的报文发送队列中;其中,所述发送者应用与所述接收者应用之间维护的初始报文序号相同,且报文序号的确定方法相同;根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述报文发送队列中的报文。
【专利说明】报文传输方法及设备
【技术领域】
[0001]本发明涉及通信【技术领域】,尤其涉及报文传输方法及设备。
【背景技术】
[0002]在网络迅猛发展的今天,人与人之间,或设备与设备之间,亦或是人与设备之间通过网络进行通信,通常采用的通信方式是传输控制协议(Transmission ControlProtocol, TCP)/ 用户数据报协议(User Datagram Protocol, UDP)等。
[0003]TCP是基于字节流的一种通信协议,在使用TCP时需要通过三次握手较繁琐流程建立点到点连接方可通信,而且通信双方需要事先对字节流进行约定,并进行必要解析处理,先发送的数据先到达。而UDP则是一种基于报文的无线连接通信协议,支持一点到多点的通信模式,报文可由应用自行定义,数据以报文为单位在接收者和发送者之间传送,而且发送者和接收者之间可不绑定,一个发送者可向多于一个接收者发送数据报文。但由于网络之间数据转发路径可能存在多条,数据转发不能完全保序,即先发数据未必先到。
[0004]在网元设备中也存在不同处理节点间数据通信的需求,且希望通信简单可靠,SP不同节点之间以报文为单位转发数据,且做到先发先到。
[0005]目前,在通信领域中,通常是基于TCP协议进行可靠通信。众所周知,TCP通信是基于字节流的一种可靠通信方式,并且在通信之前需要通信双方通过“三次握手”建立虚拟连接。而欲做到面向报文(datagram)的保序通信,还需在其上自定义报文格式来实现面向报文的通信,即需进行字节流分析完成应用报文封装,解封装等处理。
[0006]另外,在有些场景下,例如安全的局域网环境中,诸多节点告警上报,数据发送是单向的,若使用TCP通信方式,不仅需要复杂的“三次握手”,还需要字节流向报文转换,开销就很大。
[0007]综上,通信节点之间采用TCP进行面向报文保序通信,应用除了通过较为复杂过程建立通信节点间连接关系外,还需将字节流向报文的转化。这样,应用处理起来就很不方便,而采用UDP方式,无法实现报文的保序通信。

【发明内容】

[0008]本发明实施例提供了报文传输方法及设备,用以实现报文的保序通信。
[0009]本发明实施例提供的一种报文传输方法,包括:
[0010]确定发送者应用需要发送给接收者应用的报文;
[0011]确定所述发送者应用与所述接收者应用之间的关联关系,其中,所述关联关系包括:所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系;
[0012]按照报文发往所述接收者应用的发送顺序确定所述报文对应的报文序号,并利用所述报文序号对所述报文进行封装后存储到所述关联关系对应的报文发送队列中;其中,所述发送者应用与所述接收者应用之间维护的初始报文序号相同,且报文序号的确定方法相同;
[0013]根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述报文发送队列中的报文。
[0014]通过该方法,实现了报文的保序传输,简单有效地保证了收发应用之间经多路径传送业务数据时,发送者应用数据报文可按序到达接收者应用。
[0015]较佳地,该方法还包括预先建立所述发送者应用与所述接收者应用之间的关联关系的步骤:
[0016]通过预先约定的所述发送者与所述接收者之间的会话控制端口号,建立所述发送者应用与所述接收者应用之间的关联关系,其中,所述会话控制端口号包括发送控制端口和接收控制端口号。
[0017]较佳地,通过查找本地维护的接收者队列列表,确定所述发送者应用与所述接收者应用之间的关联关系。
[0018]较佳地,该方法还包括:
[0019]若发送者本地维护的接收者队列列表中没有所述发送者应用与所述接收者应用之间的关联关系,则在所述接收者队列列表中创建一表项,将所述发送者应用与所述接收者应用之间的关联关系以及所述发送者应用需要发送给所述接收者应用的报文的初始发送序号存入该表项,并创建与该表项对应的报文发送队列。
[0020]较佳地,利用所述报文序号对所述报文进行封装后存储到所述关联关系对应的报文发送队列中之后,该方法还包括:
[0021]通过预先约定的所述发送者与所述接收者之间的会话控制端口号,向所述接收者发送初始发送序号通告消息;
[0022]所述根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述发送队列中的报文,包括:
[0023]当接收到所述接收者返回的初始发送序号通告确认消息后,根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述发送队列中的报文。
[0024]本发明实施例提供的一种报文传输方法,包括:
[0025]对接收到的经封装的报文进行解封装,获取其中携带的报文序号,其中,该报文序号是发送者按照报文发往接收者应用的发送顺序确定的;
[0026]确定所述报文对应的发送者应用与接收者应用之间的关联关系,其中,所述关联关系仅包括所述接收者应用的接收者IP地址和UDP端口号,或者,所述关联关系包括:所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系;
[0027]确定所述关联关系对应的报文发送队列,并判断该报文发送队列中期望接收的报文的报文发送序号是否与所述报文的报文序号相同,如果是,则调用所述接收者应用的回调函数对所述报文进行处理,否则,将该报文及其对应的报文序号存储到所述报文发送队列中或丢弃。
[0028]通过该方法,能够实现报文的保序传输,简单有效地保证了收发应用之间经多路径传送业务数据时,发送者应用数据报文可按序到达接收者应用。
[0029]较佳地,当所述报文的报文序号大于所述期望接收的报文的报文发送序号时,将该报文及其对应的报文序号存储到所述报文发送队列中,当所述报文的报文序号小于所述期望接收的报文的报文发送序号时,丢弃该报文。
[0030]较佳地,该方法还包括预先建立所述发送者应用与所述接收者应用之间的关联关系的步骤:
[0031]通过预先约定的所述发送者与所述接收者之间的会话控制端口号,建立所述发送者应用与所述接收者应用之间的关联关系,其中,所述会话控制端口号包括发送控制端口和接收控制端口号。
[0032]较佳地,通过查找本地维护的发送者队列列表,确定所述发送者应用与所述接收者应用之间的关联关系。
[0033]较佳地,在接收所述报文之前,该方法还包括:
[0034]通过预先约定的发送者与接收者之间的会话控制端口号,接收所述发送者发送的初始发送序号通告消息,从中获取所述发送者应用发给所述接收者应用的报文的初始发送序号;
[0035]判断本地维护的发送者队列列表中是否存在所述发送者应用与所述接收者应用之间的关联关系;
[0036]若已存在的所述发送者应用与所述接收者应用之间的关联关系包括所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系,但尚未获取到发送者初始发送序号,则记录所述初始发送序号与该关联关系的对应关系,并发送初始发送序号通告确认消息给所述发送者;
[0037]若不存在仅包括所述接收者应用的接收者IP地址和UDP端口号的所述发送者应用与所述接收者应用之间的关联关系,则直接向所述发送者返回初始发送序号通告确认失败消息;
[0038]若已存在的所述发送者应用与所述接收者应用之间的关联关系仅包括所述接收者应用的接收者IP地址和UDP端口号,则在接收者维护的发送者队列中新创建所述发送者应用与所述接收者应用之间的关联关系,该关联关系为所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系,记录所述初始发送序号与该关联关系的对应关系,并发送初始发送序号通告确认消息给所述发送者。
[0039]本发明实施例提供的一种报文传输设备,包括:
[0040]报文确定单元,用于确定发送者应用需要发送给接收者应用的报文;
[0041]关联关系确定单元,用于确定所述发送者应用与所述接收者应用之间的关联关系,其中,所述关联关系包括:所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系;
[0042]报文封装单元,用于按照报文发往所述接收者应用的发送顺序确定所述报文对应的报文序号,并利用所述报文序号对所述报文进行封装后存储到所述关联关系对应的报文发送队列中;其中,所述发送者应用与所述接收者应用之间维护的初始报文序号相同,且报文序号的确定方法相同;
[0043]发送单元,用于根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述报文发送队列中的报文。[0044]通过该设备,实现了报文的保序传输,简单有效地保证了收发应用之间经多路径传送业务数据时,发送者应用数据报文可按序到达接收者应用。
[0045]较佳地,所述关联关系确定单元还用于:
[0046]通过预先约定的所述发送者与所述接收者之间的会话控制端口号,建立所述发送者应用与所述接收者应用之间的关联关系,其中,所述会话控制端口号包括发送控制端口和接收控制端口号。
[0047]较佳地,所述关联关系确定单元通过查找本地维护的接收者队列列表,确定所述发送者应用与所述接收者应用之间的关联关系。
[0048]较佳地,所述关联关系确定单元还用于:
[0049]若发送者本地维护的接收者队列列表中没有所述发送者应用与所述接收者应用之间的关联关系,则在所述接收者队列列表中创建一表项,将所述发送者应用与所述接收者应用之间的关联关系以及所述发送者应用需要发送给所述接收者应用的报文的初始发送序号存入该表项,并创建与该表项对应的报文发送队列。
[0050]较佳地,所述发送单元,在所述关联关系确定单元利用所述报文序号对所述报文进行封装后存储到所述关联关系对应的报文发送队列中之后,还用于:通过预先约定的所述发送者与所述接收者之间的会话控制端口号,向所述接收者发送初始发送序号通告消息;
[0051]所述发送单元根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述发送队列中的报文时,具体用于:当接收到所述接收者返回的初始发送序号通告确认消息后,根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述发送队列中的报文。
[0052]本发明实施例提供的一种报文传输设备,包括:
[0053]解封装单元,用于对接收到的经封装的报文进行解封装,获取其中携带的报文序号,其中,该报文序号是发送者按照报文发往接收者应用的发送顺序确定的;
[0054]关联关系确定单元,用于确定所述报文对应的发送者应用与接收者应用之间的关联关系,其中,所述关联关系仅包括所述接收者应用的接收者IP地址和UDP端口号,或者,所述关联关系包括:所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系;
[0055]判断单元,用于确定所述关联关系对应的报文发送队列,并判断该报文发送队列中期望接收的报文的报文发送序号是否与所述报文的报文序号相同,如果是,则调用所述接收者应用的回调函数对所述报文进行处理,否则,将该报文及其对应的报文序号存储到所述报文发送队列中或丢弃。
[0056]通过该设备,实现了报文的保序传输,简单有效地保证了收发应用之间经多路径传送业务数据时,发送者应用数据报文可按序到达接收者应用。
[0057]较佳地,当所述报文的报文序号大于所述期望接收的报文的报文发送序号时,将该报文及其对应的报文序号存储到所述报文发送队列中,当所述报文的报文序号小于所述期望接收的报文的报文发送序号时,丢弃该报文。
[0058]较佳地,所述关联关系确定单元还用于:
[0059]通过预先约定的所述发送者与所述接收者之间的会话控制端口号,建立所述发送者应用与所述接收者应用之间的关联关系,其中,所述会话控制端口号包括发送控制端口和接收控制端口号。
[0060]较佳地,所述关联关系确定单元通过查找本地维护的发送者队列列表,确定所述发送者应用与所述接收者应用之间的关联关系。
[0061]较佳地,所述判断单元,还用于:
[0062]在接收所述报文之前,通过预先约定的发送者与接收者之间的会话控制端口号,接收所述发送者发送的初始发送序号通告消息,从中获取所述发送者应用发给所述接收者应用的报文的初始发送序号;
[0063]判断本地维护的发送者队列列表中是否存在所述发送者应用与所述接收者应用之间的关联关系;
[0064]若已存在的所述发送者应用与所述接收者应用之间的关联关系包括所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系,但尚未获取到发送者初始发送序号,则记录所述初始发送序号与该关联关系的对应关系,并发送初始发送序号通告确认消息给所述发送者;
[0065]若不存在仅包括所述接收者应用的接收者IP地址和UDP端口号的所述发送者应用与所述接收者应用之间的关联关系,则直接向所述发送者返回初始发送序号通告确认失败消息;
[0066]若已存在的所述发送者应用与所述接收者应用之间的关联关系仅包括所述接收者应用的接收者IP地址和UDP端口号,则在接收者维护的发送者队列中新创建所述发送者应用与所述接收者应用之间的关联关系,该关联关系为所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系,记录所述初始发送序号与该关联关系的对应关系,并发送初始发送序号通告确认消息给所述发送者。
【专利附图】

【附图说明】
[0067]图1为本发明实施例提供的PSDC模型示意图;
[0068]图2为本发明实施例提供的PSDC-S组成示意图;
[0069]图3为本发明实施例提供的ISN通告消息报文格式示意图;
[0070]图4为本发明实施例提供的ISN通告确认消息报文格式示意图;
[0071]图5为本发明实施例提供的业务报文格式示意图;
[0072]图6为本发明实施例提供的PSDC-S报文保序控制模式示意图;
[0073]图7为本发明实施例提供的数据报文确认通告消息格式示意图;
[0074]图8为本发明实施例提供的AR终止通告消息格式示意图;
[0075]图9为本发明实施例提供的PSDC-R组成示意图;
[0076]图10为本发明实施例提供的一种报文传输方法的流程示意图;
[0077]图11为本发明实施例提供的另一种报文传输方法的流程示意图;
[0078]图12为本发明实施例提供的一种报文传输设备的结构示意图;
[0079]图13为本发明实施例提供的另一种报文传输设备的结构示意图。【具体实施方式】
[0080]本发明实施例提供了 一种报文传输方法及设备,用以实现报文的保序通信。
[0081]在数据通信领域中,出于可靠性或大带宽考虑,两个通信节点间往往存在多条路由或转发路径,这样,互相通信的两节点间的数据报文转发时序(即先发出先到达)就难以保证了。另外,出于性能考虑,每个通信节点往往使用多核处理器,每个核都可能接收来自网络上的数据包,这样一来,数据包到达应用也存在报文时序不正确的可能。但在网元分布式节点通信时存在保序通信要求,即一个通信节点向其它通信节点发送数据报文时,期望能有序到达,即先发出的报文先到达对端节点。
[0082]本发明实施例提出一种报文有序交付控制(Packet Sequential DeliveryControl,PSDC)方案,使得在网元中或某些分布式应用场景中,应用发送的消息保序到达指定目的地,但对应用呈现的接口依旧为类似UDP的简单通信。
[0083]在本发明实施例所给出的方案中,通信节点间事先约定会话控制端口号,包括发送控制端口和接收控制端口号。通过它们,通信处理实体根据上层应用报文发送要求,与指定节点建立关联(Association Relation, AR)关系,之后该应用的相关报文均基于所建关联关系通过UDP方式在指定节点和本地节点间进行转发。此外,若上层应用不再使用底层提供的保序通信服务,可显式删除关联,或通信处理实体根据已建关联的保持定时器触发自动删除关联。
[0084]本发明实施例涉及发送者(PacketSequential Delivery Control for Sender,PSDC-S)和接收者(Packet Sequential Delivery Control for Receiver, PSDC-R)两种通信处理实体。下面对其功能分别进行说明。
[0085]本发明实施例中,在PSDC-S和PSDC-R两端,分别维护有两个列表。
[0086]PSDC-S 维护的是接收者队列(Remote Node data Queue for receiver, RNQr)列表,该列表可以包括一个或多个表项,其中,任意一个表项用于保存本PSDC-S和一个PSDC-R的关联关系,以及发往该PSDC-R的报文发送队列(Sending Queue,SQ),其中,该SQ中保存待发送给该PSDC-R的报文,每一报文对应一发送序列号(Sequence Number, SN),SN是按照报文的发送顺序依次编排的,例如,第一个待发送的报文的SN,即初始发送序列号(Initial Sequence Number, I SN)为0,第二个待发送的报文的SN为1,第三个待发送的报文的SN为2,以此类推。
[0087]其中,同一发送者应用与同一接收者应用之间维护的初始报文序号相同,且报文序号的递增规则相同,当报文序号达到预设的最大值后,又重新置为初始序号O。
[0088]同理,PSDC-R维护的是发送者队列(RemoteNode Queue for sender,RNQs)列表,该列表可以包括一个或多个表项,其中,任意一个表项用于保存本PSDC-R和一个PSDC-S的关联关系,以及该PSDC-S发往本PSDC-R的报文的发送队列(Sending Queue,SQ),其中,该SQ中保存待上报给本PSDC-R中相应应用的来自该PSDC-S的报文,每一报文对应一发送序列号(Sequence Number, SN),SN是按照该PSDC-S发送给本PSDC-R报文的发送顺序依次编排的,例如,第一个发送的报文的SN,即初始发送序列号(Initial Sequence Number, I SN)为0,第二个发送的报文的SN为I,第三个发送的报文的SN为2,以此类推。
[0089]其中,PSDC-R和 PSDC-S 的关联关系,即 PSDC-S 的 IP 地址(IP for sender, IPs)和 UDP端口号(Data Port for sender, DPs),与 PSDC-R 的 IP 地址(IP for receiver, IPr)和 UDP 端口号(Data Port for receiver, DPr)的对应关系。
[0090]通过这种机制,简单有效地保证了收发应用之间经多路径传送业务数据时,发送者应用数据报文可按序到达接收者应用。
[0091 ] 如下分别对PSDC-S和PSDC-R功能进行说明。
[0092]发送者PSDC-S功能:
[0093]数据发送者应用,例如图1中应用(APPlication,APP)#1,调用PSDC-S提供的发送接口向PSDC-R发送数据报文,发送数据涉及本地IP地址(IP for sender, IPs)和UDP端口号(Data Port for sender, DPs),远端 IP 地址(IP for receiver, I Pr)和 UDP 端口号(Data Port for receiver, DPr)。
[0094]PSDC-S查找其维护的RNQr列表,查找的关键字为四元组(简称PSD四元组):IPs、DPs、IPr 和 DPr。
[0095]若查找不到,则创建一个表项,记录上述四元组,以及初始发送序列号(InitialSequence Number, ISN),ISN取值为0,同时创建一个与前述表项对应的报文发送队列(Sending Queue,SQ),用于将APP#1欲发送数据报文经过序号封装后暂存入其中。同时,通过IPs和发送者控制UDP端口(Control Port for sender, CPs)所确定的套接字(socket),向四元组中的IPr和UDP控制端口号(Control Port for receiver, CPr)所确定的接收者发起ISN通告消息,并等待接收ISN通告确认消息。PSDC-S在接收到来自指定PSDC-R的ISN通告确认后,将SQ中缓存报文依次按照前述四元组调用底层UDP通信接口(如操作系统(Operating System, OS)的 socket 发送接口 )发送出去。
[0096]若查找到,直接进行APP#1欲发送数据报文序号(Sequence Number, SN)封装,并存入相应SQ中。所封装序号应为相应SQ中最后一个数据报文所封装的SN+1。若相应SQ当前为空,则所封装的序号应为相应SQ中期望接收的报文的SN。需要说明的,在应用发送报文且相应SQ当前为空,需将对应SQ中期望接收的报文的SN执行加一操作(即SN =SN+I)。
[0097]具体处理参见后面关于接收者PSDC-S的相关描述。
[0098]接收者PSDC-R功能:
[0099]数据接收者应用,例如图1中APP#2,向本地PSDC-R注册本地IP地址IPr、UDP端口号DPr、发送者IP地址IPs和UDP端口号DPs (其中,IPs和DPs可选),以及数据接收回调接口函数,若仅注册IPr和DPrJU PSDC-R所接收到的UDP报文的目的IP、UDP端口号与IPr、DPr分别相同,即可交付于APP#2,否则,还需对所接收到的UDP报文源IP、UDP端口号,分别与IPs、DPs进行再匹配,仅有全匹配报文才交付于APP#2。
[0100]PSDC-R在由IPr和CPr所确定的socket上接收到来自PSDC-S发送的ISN通告后,查询其维护的以PSD四元组或二元组(即由IPr和DPr组合的元组)为关键字的远端节点(即发送节点)在RNQs列表中是否存在匹配项,即数据接收者的应用是否已在PSDC-R注册。
[0101]若已存在四元组,但尚未获取到发送者初始发送序号,则记录所述初始发送序号与该关联关系的对应关系,并发送初始发送序号通告确认消息给所述发送者。该确认消息通过IPr和CPr所确定的socket,由PSDC-R发往由IPs和CPs所确定的发起者PSDC-S的socket。[0102]若不存在仅包括所述接收者应用的接收者IP地址和UDP端口号的所述发送者应用与所述接收者应用之间的关联关系,则直接向所述发送者返回初始发送序号通告确认失败消息。
[0103]若仅存在二元组(即未与发送者建立关联,已存在的所述发送者应用与所述接收者应用之间的关联关系仅包括所述接收者应用的接收者IP地址和UDP端口号),则在查找到的RNQs中记录ISN通告消息中指定的ISN,以及PSD四元组信息,并向发送者PSDC-S返回ISN通告确认响应消息。
[0104]PSDC-R在IPr和DPr上接收到由PSDC-S发送的经封装的应用数据报文后取出其中携带的SN(记为SNs)。再基于PSD四元组查找RNQr队列,找到匹配的RNQs表项,将匹配的RNQs表项中保存的当前SN (记为SNr)和SNs进行比较,若相同,则通过回调接口将数据递交给应用APP#2处理。否则,若SNs小于SNr,则丢弃该应用数据报文,若SNs大于SNr,则将该应用数据报文及其对应的SNs存入RNQs中的与该PSD四元组所匹配的表项。
[0105]下面分别介绍PSDC-S和PSDC-R的组成及具体处理流程。
[0106]发送者PSDC-S:
[0107]PSDC-S由两部分组成,如图2所示,一个是远程节点包序号控制块管理器(RmtNodePktSeqNo Manager), 一个是远程节点包序号控制块(RmtNodeSeqNo)列表。PSDC-S根据所维护的远程节点包序号,对上层应用欲发送报文进行序号(Sequence Number, SN)封装,并发送至目的节点。SN从OxO (十六进制)开始,最大为OxFFFFFFFF (十六进制)。
[0108]PSDC-S工作时首先指派IP地址IPs,以及一个本地UDP端口号,即控制端口号CPs,用于发送者和接收者关联(Association Relation, AR)建立,以及数据报文到达确认等控制类消息收发,并为上层应用提供以下接口:
[0109]注册接口(psdcsRegister),注册输入内容包括IPs和DPs。注册成功后,应用获得发送实例号(SendInstance),该 SendInstance 在 PSDC-S 内唯一。
[0110]去注册接口(psdcsDeregister),去注册输入内容包括Sendlnstance、IPr 和 DPr。其中IPr和DPr可选。若不存在可选项,则从PSDC - S中清除与Sendlnstance相对应的以IPs和DPs为元素的所有关联AR,其中AR是由IPs、DPs、IPr和DPr唯一确定的一个通信收发实体对,并通告这些AR的PSDC - R,即由IPr和DPr唯一确定的PSDC-R,清除相应接收控制实例,即与通知者PSDC-S相关的控制块,例如接收队列、状态机等信息。若存在可选项,则仅清除由Sendlnstance和IPr、DPr共同确定的关联AR,并通告该AR的PSDC - R,清除相应接收通信处理实体。
[0111]发送接口(psdcsSend),其输入内容包括Sendlnstance、IPr和DPr,以及待发送数据(DataBlock)、待发送数据长度(DataLen)。应用使用该接口向指定节点发送业务数据。
[0112]查询接口(psdcsQuery),其输入内容包括Sendlnstance、IPr和DPr,以及返回对应AR当前状态。应用可使用该接口查询与所关心节点之间的关联关系状态,作为应用发送报文频度控制的参考。
[0113]PSDC-S执行下述过程:
[0114]步骤一:接收应用注册
[0115]当上层应用调用PSDC-S注册接口 psdcsRegister执行IPs和DPs注册时,PSDC-S为其分配PSDC-S范围内唯一的Sendlnstance标识(4字节整数),同时记录所分配的Sendlnstance 和 IPs、DPs 的对应关系。
[0116]步骤二:接收应用业务数据
[0117]应用注册之后,调用psdcsSend接口发送数据时,PSDC-S将Sendlnstance、IPr和DPr (实质上为IPs、DPs、IPr、DPr四元组,简称PSD四元组)保存下来(假如该四元组之前未保存的话)。PSD四元组作为包序号控制块索引。
[0118]若PSD四元组不存在,则向目的节点PSDC-R的控制端口 CPr (即由IPr和CPr决定的socket)发起注册(即ISN Notification消息)以告知其ISN,并接收来自目的节点的 ISN 通告确认(Notification Acknowledgement)消息,完成 PSDC-S 和 PSDC-R 之间 AR的建立。具体消息如下所述:
[0119]ISN通告消息(ISN Notification)包括:
[0120]本地IPs 和 UDP 端口号 DPs ;
[0121 ]远端 IPr 和 UDP 端口号 DPr ;
[0122]流水号标识(Identifier)(唯一标识该ISN通告消息);
[0123]ISN。
[0124]可选的,ISN通告消息(ISN Notification)还可以包括:PSDC-R进行数据报文确认的频度参数,即两次确认报文之间持续时间间隔(AckInterval)及报文累计数量(AckPktAmount)。
[0125]具体ISN通告消息(ISN Notification)的格式如图3所示。
[0126]其中:
[0127]消息类型(MessageType, MT):1个字节,取值I。
[0128]IP地址版本(IPV):1个字节,取值4时表示版本4的IP地址(IPV4);取值6时表示版本6的IP地址(IPV6)。
[0129]标识(Identifier):唯一标识一次ISN通告。在连续的两次ISN通告之间不同,PSDC-S以此唯一识别一对ISN通告、ISN通告确认消息的对应关系。
[0130]PSDC-S 侧 IP 地址(SIP1 ?SIP4):若 IPV = 4,则仅存在 SIP1,SIP2、SIP3 和 SIP4不关心;若IPV = 6,则SIPl?SIP4均有效。
[0131]PSDC-R 侧 IP 地址(RIP1 ?RIP4):若 IPV = 4,则仅存在 RIP1,RIP2、RIP3 和 RIP4不关心;若IPV = 6,则SIPl?SIP4均有效。
[0132]PSDC-S 侧数据端口(DPs):2 字节。
[0133]PSDC-R 侧数据端口(DPr):2 字节。
[0134]PSDC-S确定的初始报文序号(ISN):4字节。
[0135]两次确认报文之间最大持续时间间隔(AckInterval):字节。
[0136]两次确认报文之间PSDC-R接收到的报文累计数量(AckPktAmount):4字节。
[0137]ISN通告确认消息(ISN Notification Acknowledgement)包括:本地 IPs 和 DPs,远端IPr和DPr,以及Identifier。其格式如图4所示。
[0138]其中,
[0139]消息类型(MessageType, MT):1个字节,取值2。
[0140]IP地址版本(IPV):1个字节,取值4时表示版本4的IP地址(IPV4);取值6时表示版本6的IP地址(IPV6)。[0141]标识(Identifier):唯一标识一次ISN通告。PSDC-R根据接收到的ISN通告中同名信息域回填。
[0142]PSDC-S 侧 IP 地址(SIP1 ?SIP4):若 IPV = 4,则仅存在 SIP1,SIP2、SIP3 和 SIP4不关心;若IPV = 6,则SIPl?SIP4均有效。
[0143]PSDC-R 侧 IP 地址(RIP1 ?RIP4):若 IPV = 4,则仅存在 RIP1,RIP2、RIP3 和 RIP4不关心;若IPV = 6,则SIPl?SIP4均有效。
[0144]PSDC-S 侧数据端口(DPs):2 字节。
[0145]PSDC-R 侧数据端口(DPr):2 字节。
[0146]PSDC-R侧是否已成功建立与PSDC-S关联的结果(Rst):4字节。例如:取值O表示成功。取值非O表示失败,其中,取值I表示应用不存在;取值2表示关联已存在。
[0147]若PSD四元组存在,则根据该PSD四元组所对应的RmtNodeSeqNo进行报文封装并完成封装后报文的发送。
[0148]具体地,应用数据报文封装方式为,在APP#1所递交的UDP数据报文末尾追加SN字段(4字节),并更新原报文长度(Datagram Length, DL)为(DL+4)字节,具体如图5所
/Jn ο
[0149]需要说明的是:该报文是作为UDP报文净荷发送出去的。鉴于UDP基本通信是现有一种通信方式,因此不再赘述。
[0150]为保证发送报文有序性,对发送报文进行队列管理。具体而言,PSDC-S根据PSDC-R的报文确认进行发送报文队列出队操作。若出现确认报文错序,则暂不执行出队操作,直至相应确认报文从由IPs和CPs确定的socket上收到为止,或应用强行终止该通信,或指定的通信保活定时器超时为止。
[0151]以下给出PSDC-S发送控制策略。
[0152]应用调用PSDC-S发送接口 psdcsSend发送数据报文时,PSDC-S在处理完报文封装处理后,是直接发送还是暂存入RNQs队列,取决于定时器时长为两次发送之间等待时间间隔(Twait)的发送控制定时器(Sending Control Timer, SCT)是否超时,或待发送队列数据报文数量是否到达触发一次发送过程的累计发送报文数量(Atrig)。只要上述两个条件中的任一条件满足,即执行发送。但一次连续发送报文数量不超过一次连续发送报文数量(Acont),即调用底层UDP报文发送接口连续发送的报文数量。
[0153]需要说明的是:当一次连续发送过程中若出现发送失败,则立即终止本次发送。未发送的数据报文留待后续发送。
[0154]通过CPs接收来自PSDC-R期望SN,即PSDC-R断言错序时的期望报文。若PSDC-R无错序,则置错序标志(DisorderFlag)为0,否则置其为I。同时,获取PSDC-R接收缓冲区大小,作为其发送数据控制的参考。
[0155]PSDC-S接收到PSDC-R的确认通告(Ack Notification)(其中携带错序报文重发信息)后,重发ExpPtr至DisorderPtr间的报文。重发报文的发送策略与正常报文发送策略相同。
[0156]具体PSDC-S发送控制如下所述。针对尚未被PSDC-R确认(即尚未接收到已发送报文的确认消息)的报文列表如图6所示。
[0157]在图6中,AckPtr表示PSDC-S的RNQs中由PSD四元组决定的SQ队列中首先欲被确认的报文序号;ExpPtr表示PSDC-R期望接收到的报文序号;WrtPtr表示PSDC-S下一个欲被缓存的报文序号;MaxPtr表示PSDC-R当前可接收的最新报文序号。它随着ExpPtr的变化而变化。在ExpPtr和MaxPtr之间报文个数不超过0XFFFFFFFF/2。
[0158]需要说明的是,通常情况下,图6中提到的报文序号AckPtr小于或等于WrtPtr,ExpPtr小于或等于MaxPtr。但随着报文序号递增到达OXFFFFFFFF后,便回绕至O。这样,就存在ExpPtr大于MaxPtr, AckPtr大于WrtPtr的情况。
[0159]针对上述情况,对PSDC-S而言,待确认报文序号范围为:
[0160]当AckPtr小于或等于WrtPtr时,
[0161][AckPtr, WrtPtr] = (AckPtr ?WrtPtr);
[0162]或当AckPtr大于或等于WrtPtr时,
[0163][AckPtr, WrtPtr] = (AckPtr ?OXFFFFFFFF, O ?WrtPtr)。
[0164]认为PSDC-R可接收报文序号范围为:
[0165]当ExpPtr小于或等于MaxPtr时,
[0166][ExpPtr, MaxPtr] = (ExpPtr ?MaxPtr);
[0167]当ExpPtr大于或等于MaxPtr时,
[0168][ExpPtr, MaxPtr] = (ExpPtr ?OXFFFFFFFF, O ?MaxPtr)。
[0169]当接收到Ack Notification时,重发指定序号段报文。具体报文确认消息(AckNotification)包括IPs、DPs、IPr和DPr,以及期望重发的一个或多个报文的首报文序号ExpPtr及数量(Amnt),以及PSDC-R关于该AR的可接收消息个数(Br)。Br可被PSDC-S作为用户数据报文发送控制的参考。即PSDC-S重发报文是否启动取决Br是否大于零。
[0170]该消息由PSDC-R通过由IPr和CPr所决定的socket发往由IPs和CPs决定的PSDC-S的socket。数据报文确认通告消息(Ack Notification)的报文格式如图7所示,其中,
[0171]消息类型(MessageType, MT):1个字节,取值3。
[0172]IP地址版本(IPV):1个字节,取值4时表示版本4的IP地址(IPV4);取值6时表示版本6的IP地址(IPV6)。
[0173]在PSDC-R是否探测出报文错序(Disorder Flag, DF):DF取值O表示无错序;DF取值I表示错序。
[0174]保留字节(RSVD):—个字节。
[0175]SIPl ?SIP4,表示 PSDC-S 侧 IP 地址。若 IPV = 4,则仅存在 SIP1,SIP2、SIP3 和SIP4不关心;若IPV = 6,则SIPl?SIP4均有效。
[0176]RIPl ?RIP4,表示 PSDC-R 侧 IP 地址。若 IPV = 4,则仅存在 RIP1,RIP2、RIP3 和RIP4不关心;若IPV = 6,则SIPl?SIP4均有效。
[0177]PSDC-S 侧数据端口(DPs):2 字节。
[0178]PSDC-R 侧数据端口(DPr):2 字节。
[0179]PSDC-R期望的待接收数据报文序号(ExpPtr):4字节。
[0180]PSDC-R期望待重发数据报文数量(Amnt),即自ExpPtr序号开时序号连续的报文数量。
[0181]PSDC-R针对PSD四元组所决定的缓冲区大小(Br),即当时可接收报文数量。[0182]当收到的Ack Notification消息中ExpPtr为期望接收报文序号,其中Amnt = O,表明PSDC-R无新报文到达。
[0183]若ExpPtr等于WPtr,则不做处理。
[0184]若ExpPtr落在由[AckPtr, WPtr]决定的区间,则更新AckPtr为ExpPtr,并且,
[0185](a)若 Amnt = O, PSDC-S 发送位于[AckPtr, WrPtr]之间的报文。
[0186](b)若 Amnt>0, PSDC-S 重发位于[AckPtr, MaxPtr]之间的报文。
[0187]其中,MaxPtr=(ExpPtr+Amnt) % 0x100000000?
[0188]步骤三:周期探测PSDC-R心跳是否正常。
[0189]根据与PSDC-R之间建立AR时指定的数据报文接收确认周期要求,启动周期定时器检查PSDC-R是否正常。
[0190]判断依据:PSDC-R的Ack Notification消息在规定时间间隔(Twait)内未能接收到,并连续三次仍未收到,则认为PSDC-R异常。
[0191]若判断PSDC-R心跳异常,认为PSDC-R重启,PSDC-S清除相关RNQs中缓存报文,重新尝试ISN通告,恢复AR。
[0192]步骤四:接收应 用去注册,或获知PSDC-R不可达关闭AR。
[0193]PSDC-S在以下情形下执行相应AR关闭操作:
[0194]应用请求关闭指定AR ;
[0195]PSDC-R不可达超过预设时间,即PSDC-S期望的业务报文确认时间AckInterval ;
[0196]接收到来自PSDC-R 的 AR 终止通告(AR Terminiation Notification)。
[0197]PSDC-S 向 PSDC-R 发起的 AR 终止通告(AR Termination Notif ication),包括所关闭AR对应的PSD四元组信息。AR终止通告消息的格式如图8所示。
[0198]其中,
[0199]消息类型(MessageType, MT):1个字节,取值4。
[0200]IP地址版本(IPV): I个字节,取值4时表示版本4的IP地址(IPV4);取值6时表示版本6的IP地址(IPV6)。
[0201]PSDC-S终止关联关系的原因(Cause),例如:取值I表示上层应用显示关闭;取值2表示探测到PSDC-R已超过预设保活时间。
[0202]保留字节(RSVD):—个字节。
[0203]SIPl~SIP4,表示PSDC-S侧IP地址。若IPV = 4,则仅存在SIP1,不关心SIP2、SIP3 和 SIP4 ;若 IPV = 6,则 SIPl ~SIP4 均有效。
[0204]RIPl~RIP4,表示PSDC-R侧IP地址。若IPV = 4,则仅存在RIP1,不关心RIP2、RIP3 和 RIP4 ;若 IPV = 6,则 SIPl ~SIP4 均有效。
[0205]PSDC-S 侧数据端口(DPs):2 字节。
[0206]PSDC-R 侧数据端口(DPr):2 字节。
[0207]需要说明的是=PSDC-R在获知某一接收者实例(即由PSD四元组决定的实例)不存在时,也通告PSDC-S。PSDC-R向PSDC-S发送的AR终止通告与上述消息格式相同。
[0208]下面介绍接收者PSDC-R的组成及具体处理流程:
[0209]PSDC-R由两部分组成,如图9所示,一部分是远端节点状态机管理(RmtNodeFSMScheduler),另一部分是远端节点状态机(RmtNodeFSM)列表。[0210]RmtNodeFSM Scheduler根据接收的远端(发送者)发起的ISN通告请求携带的PSD四元组信息,动态创建相应RmtNodeFSM。一个RmtNodeFSM由PSD四元组唯一确定。
[0211]PSDC-R工作时首先指派本地IP地址IPr及一个本地UDP端口号,即控制端口号CPr,用于接收者和发送者之间AR的建立,以及数据报文到达确认等控制消息收发。此外,为上层应用提供以下接口:
[0212]注册接口 psdcrRegister,注册输入内容包括IPr、DPr、IPs、DPs和应用数据接收回调函数AppRecvCallback。其中IPs、DPs为可选。PSDC-R根据应用注册的是PSD四元组还是二元组(即由IPr、DPr确定的元组)来决定来自PSDC-S的报文转交应用方式。
[0213]去注册接口 psdcrDeregister,去注册输入内容包括IPr、DPr、IPs、DPs,其中IPs、DPs为可选。应用调用该接口可关闭由IPr、DPr、IPs、DPs决定的AR,或IPr、DPr决定的AR。
[0214]PSDC-R执行下述处理流程:
[0215]步骤一:接收应用注册。
[0216]完成PSDC-R可接收的IPr、DPr、IPs和DPs的指定,以及应用接收数据的回调函数的记录,并执行IPr、DPr、IPs和DPs相应socket建立,以备从中接收来自PSDC-S发来的应用数据。
[0217]步骤二:接收PSDC-S的ISN请求。
[0218]PSDC-R在接收到来自PSDC-S的ISN通告(ISN Notification)时,创建一新的RmtNodeFSM。前提是,通告中指定的IPr和DPr已在PSDC-R注册,并且由ISN Notification中PSD四元组所决定的RmtNodeFSM不存在。同时,向PSDC-S返回ISN NotificationAcknowledgement响应消息。具体如下所述:
[0219]接收来自PSDC-S的ISN Notification后,根据请求中的应用是否注册,以决定ISN Notification Acknowledgement 消息的填写。
[0220]若ISN请求的应用未注册,则向发起者返回失败ISN NotificationAcknowledgement消息,其中携带失败原因为“应用不存在”。
[0221]若ISN请求的应用已注册,且PSD四元组决定的RmtNodeFSM已存在,则向发起者返回失败ISN Notification Acknowledgement消息,其中携带失败原因为“关联已存在”。
[0222]若ISN请求的应用已注册,且PSD四元组决定的RmtNodeFSM不存在,则向发起者返回成功ISN Acknowledgement消息。并且,从ISN中获取为PSDC-R指定数据报文确认的频度参数,即两次确认报文之间持续时间间隔AckInterval及报文累计数量AckPktAmount取值。
[0223]需要说明的,在与PSDC-S完成ISN同步后,定时或定量向其发送AckNotification0即使无待确认报文,也需发Ack Notification报文,用于PSDC-R和PSDC-S间心跳探测。
[0224]以下对RmtNodeFSM工作过程进行说明。
[0225]RmtNodeFSM涉及两个状态:交付就绪态(DeliverReady)和纠序态(AdjustSeq)。DSDC-R在接收到PSDC-S的ISN Notification后创建RmtNodeFSM,并使其处于DeliverReady 态。以下对 DeliverReady、AdjustSeq 分别进行说明。
[0226]DeliverReady 状态:[0227]在该状态下,若接收到来自DSCP-S的数据报文序号为期望的ExpPtr时,即可将其交付应用,状态保持不变。
[0228]若接收到来自DSCP-S的AR终止通告(Terminiation Notification)时,清除该RmtNodeFSM。
[0229]DSDC-R在接收到PSDC-S的数据报文序号非所期望序号(ExpPtr)时,启动纠序定时器(DisorderAdjTimer),并进入 AdjustSeq 态。
[0230]AdjustSeq 状态:
[0231]当DisorderAdjTimer超时后,向PSDC-S发起报文重发请求,即在AckNotification中携带期望重发的报文(具体报文参见前述说明)。RmtNodeFSM当前状态保持不变。
[0232]若接收到来自rosc-s的非期望报文,但报文序号有效,则缓存于相应AR的接收缓冲区(Receiving Buffer,RB)中。若报文序号无效,贝U直接丢弃。RmtNodeFSM当前状态保持不变。
[0233]若接收到的报文是来自PSDC-S的期望报文,则在接收到该报文时,停止DisorderAdjTimer定时器,并插入相应AR的RB首部,从RB首部开始,针对每个连续报文调用应用注册的数据接收回调函数,将报文交付给应用,同时清除RB中已交付给应用的缓存报文。直至RB中报文序号不连续为止,或RB为空为止。
[0234]若出现RB中报文序号不连续,则更新当前期望报文序号为RB中出现不连续报文序号时的下一个期望报文序号,并向PSDC-S发送Ack Notification。其中,重发报文数量为期望报文序号与最早出现不连续报文序号间报文的个数或设定的最大值(具体见下述“接收数据报文”的处理部分所述)。同时,重启DisorderAdjTimer定时器,定时器时长依照下述“接收数据报文”的处理部分所述方式计算。RmtNodeFSM当前状态保持不变。
[0235]若RB为空,则RmtNodeFSM当前状态迁移至DeliverReady。
[0236]步骤三:接收数据报文。
[0237]在收到报文序号为期望序号(ExpPtr)后,更新期望报文序号(ExpPtr)为当前序号+1 (即ExpPtr = ExpPtr+Ι),并将收到报文交付给应用。
[0238]在收到报文序号非期望序号ExpPtr后,需启动丢包或乱序调整定时器(DisorderAdjTimer),其时长(Disorder AdjInterval)按照以下方式确定。
[0239]考虑到出现报文错序后,也许期望报文随即到达,因此,在PSDC-R请求重发期望报文前延时(DisorderPtr — ExpPtr)*Tref的时间。即
[0240]Disorder AdjInterval = (DisorderPtr — ExpPtr) XTsr
[0241]其中,
[0242]DisorderPtr表示最近一次正常确认后接收到的错序报文SN。
[0243]ExpPtr表示PSDC-R所期望的数据报文序号。
[0244]Tsr表示用户数据报文在PSDC-S和PSDC-R之间传送参考时间,默认为50ms,可根据实际情况调整。
[0245]以下对DisorderAdjTimer定时器启动后的处理给出说明。
[0246]若在DisorderAdjTimer逾时前,收到期望报文(即报文序号为ExpPtr的报文),删除定时器,更新ExpPtr为ExpPtr+Ι,并将收到报文交付给应用。[0247]若超时,则向PSDC-S发送Ack Notification,其中携带PSDC-R认为丢失需PSDC-S重发的报文信息即,期望报文序号(ExpPtr)和连续报文数量(Amnt)至PSDC-S,请求后者重发指定序号段报文。其中,Amnt指的是期望报文序号与错序报文最小序号(DisorderPtr)间报文数量。考虑到错序发生时可能引起大量不必要重传,在PSDC-R发送AckNotification消息时控制Amnt最大值,例如为10、20等。
[0248]步骤四:AckNotification 报文发送。
[0249]通过CPr端口定期(以不大于PSDC-S发送的ISN Notification中携带的数据报文确认时间为周期)或定量向PSDC-S发送Ack Notification消息,以通知PSDC-S自身期望报文序号(ExpPtr),需重发的连续报文(连续报文的序号从ExpPtr开始)数量(Amnt),当前接收缓冲区大小(Br)。若PSDC-R无错序,则置错序标志DF (Disorder Flag)为0,否则置其为I。Ack Notification消息格式如图7所示。
[0250]步骤五:接收应用去注册或来自PSDC-S请求关闭AR。
[0251]接收者应用请求关闭一组实例(即由IPr和DPr共同确定的一组实例),或特定实例(即由PSD四元组决定的实例)时,PSDC-R关闭对应AR,并同时向相应PSDC-S发送ARTerminiation Notification 消息。
[0252]或接收到来自PSDC-S的AR终止通告AR Terminiation Notif ication (其中包括所关闭AR对应的PSD四元组信息)时,关闭对应AR。需要说明的是,由某一 PSDC-S触发的AR关闭,并不影响其它PSDC-S与该PSDC-R的业务发送。
[0253]综上,参见图10,在发送端,本发明实施例提供的一种报文传输方法,包括:
[0254]S101、确定发送者应用需要发送给接收者应用的报文;
[0255]S102、确定所述发送者应用与所述接收者应用之间的关联关系,其中,所述关联关系包括:所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系;
[0256]S103、按照报文发往所述接收者应用的发送顺序确定所述报文对应的报文序号,并利用所述报文序号对所述报文进行封装后存储到所述关联关系对应的报文发送队列中;其中,所述发送者应用与所述接收者应用之间维护的初始报文序号相同,且报文序号的确定方法相同;
[0257]S104、根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述报文发送队列中的报文。
[0258]较佳地,该方法还包括预先建立所述发送者应用与所述接收者应用之间的关联关系的步骤:
[0259]通过预先约定的所述发送者与所述接收者之间的会话控制端口号,建立所述发送者应用与所述接收者应用之间的关联关系,其中,所述会话控制端口号包括发送控制端口和接收控制端口号。
[0260]较佳地,通过查找本地维护的接收者队列列表,确定所述发送者应用与所述接收者应用之间的关联关系。
[0261 ] 较佳地,该方法还包括:
[0262]若发送者本地维护的接收者队列列表中没有所述发送者应用与所述接收者应用之间的关联关系,则在所述接收者队列列表中创建一表项,将所述发送者应用与所述接收者应用之间的关联关系以及所述发送者应用需要发送给所述接收者应用的报文的初始发送序号存入该表项,并创建与该表项对应的报文发送队列。
[0263]较佳地,利用所述报文序号对所述报文进行封装后存储到所述关联关系对应的报文发送队列中之后,该方法还包括:
[0264]通过预先约定的所述发送者与所述接收者之间的会话控制端口号,向所述接收者发送初始发送序号通告消息;
[0265]所述根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述发送队列中的报文,包括:
[0266]当接收到所述接收者返回的初始发送序号通告确认消息后,根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述发送队列中的报文。
[0267]相应地,在接收端,参见图11,本发明实施例提供的一种报文传输方法,包括步骤:
[0268]S201、对接收到的经封装的报文进行解封装,获取其中携带的报文序号,其中,该报文序号是发送者按照报文发往接收者应用的发送顺序确定的;
[0269]S202、确定所述报文对应的发送者应用与接收者应用之间的关联关系,其中,所述关联关系仅包括所述接收者应用的接收者IP地址和UDP端口号,或者,所述关联关系包括:所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系;
[0270]S203、确定所述关联关系对应的报文发送队列,并判断该报文发送队列中期望接收的报文的报文发送序号是否与所述报文的报文序号相同,如果是,则调用所述接收者应用的回调函数对所述报文进行处理,否则,将该报文及其对应的报文序号存储到所述报文发送队列中或丢弃。
[0271]较佳地,当所述报文的报文序号大于所述期望接收的报文的报文发送序号时,将该报文及其对应的报文序号存储到所述报文发送队列中,当所述报文的报文序号小于所述期望接收的报文的报文发送序号时,丢弃该报文。
[0272]较佳地,该方法还包括预先建立所述发送者应用与所述接收者应用之间的关联关系的步骤:
[0273]通过预先约定的所述发送者与所述接收者之间的会话控制端口号,建立所述发送者应用与所述接收者应用之间的关联关系,其中,所述会话控制端口号包括发送控制端口和接收控制端口号。
[0274]较佳地,通过查找本地维护的发送者队列列表,确定所述发送者应用与所述接收者应用之间的关联关系。
[0275]较佳地,在接收所述报文之前,该方法还包括:
[0276]通过预先约定的发送者与接收者之间的会话控制端口号,接收所述发送者发送的初始发送序号通告消息,从中获取所述发送者应用发给所述接收者应用的报文的初始发送序号;
[0277]判断本地维护的发送者队列列表中是否存在所述发送者应用与所述接收者应用之间的关联关系;
[0278]若已存在的所述发送者应用与所述接收者应用之间的关联关系包括所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系,但尚未获取到发送者初始发送序号,则记录所述初始发送序号与该关联关系的对应关系,并发送初始发送序号通告确认消息给所述发送者;
[0279]若不存在仅包括所述接收者应用的接收者IP地址和UDP端口号的所述发送者应用与所述接收者应用之间的关联关系,则直接向所述发送者返回初始发送序号通告确认失败消息;
[0280]若已存在的所述发送者应用与所述接收者应用之间的关联关系仅包括所述接收者应用的接收者IP地址和UDP端口号,则在接收者维护的发送者队列中新创建所述发送者应用与所述接收者应用之间的关联关系,该关联关系为所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系,记录所述初始发送序号与该关联关系的对应关系,并发送初始发送序号通告确认消息给所述发送者。
[0281]相应地,参见图12,在发送端,本发明实施例提供的一种报文传输设备,包括:
[0282]报文确定单元11,用于确定发送者应用需要发送给接收者应用的报文;
[0283]关联关系确定单元12,用于确定所述发送者应用与所述接收者应用之间的关联关系,其中,所述关联关系包括:所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系;
[0284]报文封装单元13,用于按照报文发往所述接收者应用的发送顺序确定所述报文对应的报文序号,并利用所述报文序号对所述报文进行封装后存储到所述关联关系对应的报文发送队列中;其中,所述发送者应用与所述接收者应用之间维护的初始报文序号相同,且报文序号的确定方法相同;
[0285]发送单元14,用于根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述报文发送队列中的报文。
[0286]较佳地,所述关联关系确定单元12还用于:
[0287]通过预先约定的所述发送者与所述接收者之间的会话控制端口号,建立所述发送者应用与所述接收者应用之间的关联关系,其中,所述会话控制端口号包括发送控制端口和接收控制端口号。
[0288]较佳地,所述关联关系确定单元12通过查找本地维护的接收者队列列表,确定所述发送者应用与所述接收者应用之间的关联关系。
[0289]较佳地,所述关联关系确定单元12还用于:
[0290]若发送者本地维护的接收者队列列表中没有所述发送者应用与所述接收者应用之间的关联关系,则在所述接收者队列列表中创建一表项,将所述发送者应用与所述接收者应用之间的关联关系以及所述发送者应用需要发送给所述接收者应用的报文的初始发送序号存入该表项,并创建与该表项对应的报文发送队列。
[0291]较佳地,所述发送单元14,在所述关联关系确定单元12利用所述报文序号对所述报文进行封装后存储到所述关联关系对应的报文发送队列中之后,还用于:通过预先约定的所述发送者与所述接收者之间的会话控制端口号,向所述接收者发送初始发送序号通告消息;
[0292]所述发送单元14根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述发送队列中的报文时,具体用于:当接收到所述接收者返回的初始发送序号通告确认消息后,根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述发送队列中的报文。
[0293]参见图13,本发明实施例提供的一种报文传输设备,包括:
[0294]解封装单元21,用于对接收到的经封装的报文进行解封装,获取其中携带的报文序号,其中,该报文序号是发送者按照报文发往接收者应用的发送顺序确定的;
[0295]关联关系确定单元22,用于确定所述报文对应的发送者应用与接收者应用之间的关联关系,其中,所述关联关系仅包括所述接收者应用的接收者IP地址和UDP端口号,或者,所述关联关系包括:所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系;
[0296]判断单元23,用于确定所述关联关系对应的报文发送队列,并判断该报文发送队列中期望接收的报文的报文发送序号是否与所述报文的报文序号相同,如果是,则调用所述接收者应用的回调函数对所述报文进行处理,否则,将该报文及其对应的报文序号存储到所述报文发送队列中或丢弃。
[0297]较佳地,当所述报文的报文序号大于所述期望接收的报文的报文发送序号时,将该报文及其对应的报文序号存储到所述报文发送队列中,当所述报文的报文序号小于所述期望接收的报文的报文发送序号时,丢弃该报文。
[0298]较佳地,所述关联关系确定单元22还用于:
[0299]通过预先约定的所述发送者与所述接收者之间的会话控制端口号,建立所述发送者应用与所述接收者应用之间的关联关系,其中,所述会话控制端口号包括发送控制端口和接收控制端口号。
[0300]较佳地,所述关联关系确定单元22通过查找本地维护的发送者队列列表,确定所述发送者应用与所述接收者应用之间的关联关系。
[0301]较佳地,所述判断单元23,还用于:
[0302]在接收所述报文之前,通过预先约定的发送者与接收者之间的会话控制端口号,接收所述发送者发送的初始发送序号通告消息,从中获取所述发送者应用发给所述接收者应用的报文的初始发送序号;
[0303]判断本地维护的发送者队列列表中是否存在所述发送者应用与所述接收者应用之间的关联关系;
[0304]若已存在的所述发送者应用与所述接收者应用之间的关联关系包括所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系,但尚未获取到发送者初始发送序号,则记录所述初始发送序号与该关联关系的对应关系,并发送初始发送序号通告确认消息给所述发送者;
[0305]若不存在仅包括所述接收者应用的接收者IP地址和UDP端口号的所述发送者应用与所述接收者应用之间的关联关系,则直接向所述发送者返回初始发送序号通告确认失败消息;
[0306]若已存在的所述发送者应用与所述接收者应用之间的关联关系仅包括所述接收者应用的接收者IP地址和UDP端口号,则在接收者维护的发送者队列中新创建所述发送者应用与所述接收者应用之间的关联关系,该关联关系为所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系,记录所述初始发送序号与该关联关系的对应关系,并发送初始发送序号通告确认消息给所述发送者。
[0307]综上所述,使用本发明提出的方案,可简单有效保证收发应用之间经多路径传送业务数据时,发送者应用数据报文可按序到达接收者应用。控制消息和业务数据通过不同UDP端口转发,这样一来,在网络发生拥塞情况下,可方便通过在中间交换节点配置QOS调度控制策略(如基于源目IP和UDP端口等进行QOS队列设置),从而保证控制消息优先转发,尽可能避免业务数据确认通告消息报文丢失而导致的大量不必要业务数据报文重传。本发明所提出的业务数据收发关联关系建立仅在发送和接收者之间执行一次业务数据发送序号的请求和确认。这对前面提到的告警上报等单向业务保序转发的应用场景更为适用。而对于双向保序通信的场景,仅需在欲通信的节点上同时部署收发功能模块即可。
[0308]本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
[0309]本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0310]这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0311 ] 这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0312] 显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。
【权利要求】
1.一种报文传输方法,其特征在于,该方法包括: 确定发送者应用需要发送给接收者应用的报文; 确定所述发送者应用与所述接收者应用之间的关联关系,其中,所述关联关系包括:所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系; 按照报文发往所述接收者应用的发送顺序确定所述报文对应的报文序号,并利用所述报文序号对所述报文进行封装后存储到所述关联关系对应的报文发送队列中;其中,所述发送者应用与所述接收者应用之间维护的初始报文序号相同,且报文序号的确定方法相同; 根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述报文发送队列中的报文。
2.根据权利要求1所述的方法,其特征在于,该方法还包括预先建立所述发送者应用与所述接收者应用之间的关联关系的步骤: 通过预先约定的所述发送者与所述接收者之间的会话控制端口号,建立所述发送者应用与所述接收者应用之间的关联关系,其中,所述会话控制端口号包括发送控制端口和接收控制端口号。
3.根据权利要求1所述的方法,其特征在于,通过查找本地维护的接收者队列列表,确定所述发送者应用与所述接收者应用之间的关联关系。
4.根据权利要求3所述的方法,其特征在于,该方法还包括: 若发送者本地维护的接收者队列列表中没有所述发送者应用与所述接收者应用之间的关联关系,则在所述接收者队列列表中创建一表项,将所述发送者应用与所述接收者应用之间的关联关系以及所述发送者应用需要发送给所述接收者应用的报文的初始发送序号存入该表项,并创建与该表项对应的报文发送队列。
5.根据权利要求4所述的方法,其特征在于,利用所述报文序号对所述报文进行封装后存储到所述关联关系对应的报文发送队列中之后,该方法还包括: 通过预先约定的所述发送者与所述接收者之间的会话控制端口号,向所述接收者发送初始发送序号通告消息; 根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述发送队列中的报文,包括: 当接收到所述接收者返回的初始发送序号通告确认消息后,根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述发送队列中的报文。
6.—种报文传输方法,其特征在于,该方法包括: 对接收到的经封装的报文进行解封装,获取其中携带的报文序号,其中,该报文序号是发送者按照报文发往接收者应用的发送顺序确定的; 确定所述报文对应的发送者应用与接收者应用之间的关联关系,其中,所述关联关系仅包括所述接收者应用的接收者IP地址和UDP端口号,或者,所述关联关系包括:所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系; 确定所述关联关系对应的报文发送队列,并判断该报文发送队列中期望接收的报文的报文发送序号是否与所述报文的报文序号相同,如果是,则调用所述接收者应用的回调函数对所述报文进行处理,否则,将该报文及其对应的报文序号存储到所述报文发送队列中或丢弃。
7.根据权利要求6所述的方法,其特征在于,当所述报文的报文序号大于所述期望接收的报文的报文发送序号时,将该报文及其对应的报文序号存储到所述报文发送队列中,当所述报文的报文序号小于所述期望接收的报文的报文发送序号时,丢弃该报文。
8.根据权利要求6所述的方法,其特征在于,该方法还包括预先建立所述发送者应用与所述接收者应用之间的关联关系的步骤: 通过预先约定的所述发送者与所述接收者之间的会话控制端口号,建立所述发送者应用与所述接收者应用之间的关联关系,其中,所述会话控制端口号包括发送控制端口和接收控制端口号。
9.根据权利要求6所述的方法,其特征在于,通过查找本地维护的发送者队列列表,确定所述发送者应用与所述接收者应用之间的关联关系。
10.根据权利要求9所述的方法,其特征在于,在接收所述报文之前,该方法还包括: 通过预先约定的发送者与接收者之间的会话控制端口号,接收所述发送者发送的初始发送序号通告消息,从中获取所述发送者应用发给所述接收者应用的报文的初始发送序号; 判断本地维护的发送者队列列表中是否存在所述发送者应用与所述接收者应用之间的关联关系; 若已存在的所述发送者应用与所述接收者应用之间的关联关系包括所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系,但尚未获取到发送者初始发送序号,则记录所述初始发送序号与该关联关系的对应关系,并发送初始发送序号通告确认消息给所述发送者; 若不存在仅包括所述接收者应用的接收者IP地址和UDP端口号的所述发送者应用与所述接收者应用之间的关联关系,则直接向所述发送者返回初始发送序号通告确认失败消息; 若已存在的所述发送者应用与所述接收者应用之间的关联关系仅包括所述接收者应用的接收者IP地址和UDP端口号,则在接收者维护的发送者队列中新创建所述发送者应用与所述接收者应用之间的关联关系,该关联关系为所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和m)P端口号的对应关系,记录所述初始发送序号与该关联关系的对应关系,并发送初始发送序号通告确认消息给所述发送者。
11.一种报文传输设备,其特征在于,该设备包括: 报文确定单元,用于确定发送者应用需要发送给接收者应用的报文; 关联关系确定单元,用于确定所述发送者应用与所述接收者应用之间的关联关系,其中,所述关联关系包括:所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系; 报文封装单元,用于按照报文发往所述接收者应用的发送顺序确定所述报文对应的报文序号,并利用所述报文序号对所述报文进行封装后存储到所述关联关系对应的报文发送队列中;其中,所述发送者应用与所述接收者应用之间维护的初始报文序号相同,且报文序号的确定方法相同; 发送单元,用于根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述报文发送队列中的报文。
12.根据权利要求11所述的设备,其特征在于,所述关联关系确定单元还用于: 通过预先约定的所述发送者与所述接收者之间的会话控制端口号,建立所述发送者应用与所述接收者应用之间的关联关系,其中,所述会话控制端口号包括发送控制端口和接收控制端口号。
13.根据权利要求11所述的设备,其特征在于,所述关联关系确定单元通过查找本地维护的接收者队列列表,确定所述发送者应用与所述接收者应用之间的关联关系。
14.根据权利要求13所述的设备,其特征在于,所述关联关系确定单元还用于: 若发送者本地维护的接收者队列列表中没有所述发送者应用与所述接收者应用之间的关联关系,则在所述接收者队列列表中创建一表项,将所述发送者应用与所述接收者应用之间的关联关系以及所述发送者应用需要发送给所述接收者应用的报文的初始发送序号存入该表项,并创建与该表项对应的报文发送队列。
15.根据权利要求14所述的设备,其特征在于,所述发送单元,在所述关联关系确定单元利用所述报文序号对 所述报文进行封装后存储到所述关联关系对应的报文发送队列中之后,还用于:通过预先约定的所述发送者与所述接收者之间的会话控制端口号,向所述接收者发送初始发送序号通告消息; 所述发送单元根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述发送队列中的报文时,具体用于:当接收到所述接收者返回的初始发送序号通告确认消息后,根据所述关联关系,按照先后顺序向所述接收者应用对应的接收者发送所述发送队列中的报文。
16.一种报文传输设备,其特征在于,该设备包括: 解封装单元,用于对接收到的经封装的报文进行解封装,获取其中携带的报文序号,其中,该报文序号是发送者按照报文发往接收者应用的发送顺序确定的; 关联关系确定单元,用于确定所述报文对应的发送者应用与接收者应用之间的关联关系,其中,所述关联关系仅包括所述接收者应用的接收者IP地址和UDP端口号,或者,所述关联关系包括:所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系; 判断单元,用于确定所述关联关系对应的报文发送队列,并判断该报文发送队列中期望接收的报文的报文发送序号是否与所述报文的报文序号相同,如果是,则调用所述接收者应用的回调函数对所述报文进行处理,否则,将该报文及其对应的报文序号存储到所述报文发送队列中或丢弃。
17.根据权利要求16所述的设备,其特征在于,当所述报文的报文序号大于所述期望接收的报文的报文发送序号时,将该报文及其对应的报文序号存储到所述报文发送队列中,当所述报文的报文序号小于所述期望接收的报文的报文发送序号时,丢弃该报文。
18.根据权利要求16所述的设备,其特征在于,所述关联关系确定单元还用于: 通过预先约定的所述发送者与所述接收者之间的会话控制端口号,建立所述发送者应用与所述接收者应用之间的关联关系,其中,所述会话控制端口号包括发送控制端口和接收控制端口号。
19.根据权利要求16所述的设备,其特征在于,所述关联关系确定单元通过查找本地维护的发送者队列列表,确定所述发送者应用与所述接收者应用之间的关联关系。
20.根据权利要求19所述的设备,其特征在于,所述判断单元,还用于: 在接收所述报文之前,通过预先约定的发送者与接收者之间的会话控制端口号,接收所述发送者发送的初始发送序号通告消息,从中获取所述发送者应用发给所述接收者应用的报文的初始发送序号; 判断本地维护的发送者队列列表中是否存在所述发送者应用与所述接收者应用之间的关联关系; 若已存在的所述发送者应用与所述接收者应用之间的关联关系包括所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和UDP端口号的对应关系,但尚未获取到发送者初始发送序号,则记录所述初始发送序号与该关联关系的对应关系,并发送初始发送序号通告确认消息给所述发送者; 若不存在仅包括所述接收者应用的接收者IP地址和UDP端口号的所述发送者应用与所述接收者应用之间的关联关系,则直接向所述发送者返回初始发送序号通告确认失败消息; 若已存在的所述发送者应用与所述接收者应用之间的关联关系仅包括所述接收者应用的接收者IP地址和UDP端口号,则在接收者维护的发送者队列中新创建所述发送者应用与所述接收者应用之间的 关联关系,该关联关系为所述发送者应用对应的发送者IP地址和UDP端口号,与所述接收者应用的接收者IP地址和m)P端口号的对应关系,记录所述初始发送序号与该关联关系的对应关系,并发送初始发送序号通告确认消息给所述发送者。
【文档编号】H04L12/70GK103986647SQ201410215037
【公开日】2014年8月13日 申请日期:2014年5月21日 优先权日:2014年5月21日
【发明者】王高亮 申请人:大唐移动通信设备有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1