CN108616334A - 报文传输方法及装置、系统、存储介质、电子装置 - Google Patents

报文传输方法及装置、系统、存储介质、电子装置 Download PDF

Info

Publication number
CN108616334A
CN108616334A CN201810443885.0A CN201810443885A CN108616334A CN 108616334 A CN108616334 A CN 108616334A CN 201810443885 A CN201810443885 A CN 201810443885A CN 108616334 A CN108616334 A CN 108616334A
Authority
CN
China
Prior art keywords
message
serial number
equipment
sent
loss
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201810443885.0A
Other languages
English (en)
Other versions
CN108616334B (zh
Inventor
熊勤
陈颖川
刘学安
史美康
张晓渠
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nanjing ZTE New Software Co Ltd
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to CN201810443885.0A priority Critical patent/CN108616334B/zh
Publication of CN108616334A publication Critical patent/CN108616334A/zh
Priority to PCT/CN2019/085550 priority patent/WO2019214550A1/zh
Application granted granted Critical
Publication of CN108616334B publication Critical patent/CN108616334B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0604Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/16Multipoint routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64Addressing
    • H04N21/6405Multicasting

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提供了一种报文传输方法及装置、系统、存储介质、电子装置,其中,该方法包括:接收第一设备发送的丢失报文的序号,其中,丢失报文的序号用于指示在第二设备发送给第一设备的报文中丢失报文的序号;对丢失报文的序号进行去重操作,得到丢失报文序号集合;将丢失报文序号集合发送给第二设备。通过本发明,解决了相关技术中处理丢失报文时间太长的技术问题。

Description

报文传输方法及装置、系统、存储介质、电子装置
技术领域
本发明涉及通信领域,具体而言,涉及一种报文传输方法及装置、系统、存储介质、电子装置。
背景技术
网络应用中,组播作为一种高效的传输方案,被广泛应用于视频传输、消息分发、文件推送,主流的组播方案是,基于无连接的UDP(User Data Protocol,用户数据报协议)协议封装原始数据报文,采用组播方式在网络设备中分发和传输。由于组播传输存在不可靠性,在网络异常时容易出现丢包或者误码,必须进行纠错补偿,以保证可靠性数据传输。IPTV(网路协定电视,Internet Protocol Television)\视频会议等视频业务领域中,相关技术中的组播传输方案是UDP组播+FEC(前向纠错,Forward Error Correction):对于媒体数据,发送端除了发送组播原始数据外,还会对媒体内容进行FEC纠错编码,发送FEC纠错报文,接收端可以同时接收到媒体内容的原始数据报文和FEC报文,对于丢包或者误码的原始数据报文,接收端使用FEC纠错报文对原始报文进行还原,从而大大提升媒体内容传输的质量。UDP组播+FEC方案存在的问题:FEC冗余报文只能提供部分的冗余度,原始数据报文丢包率超过FEC的冗余度的时候,FEC纠错报文依旧无法对数据进行还原;FEC纠错数据报文如果丢包,接收端将无法对原始数据报文进行还原。
为了实现更加高效的可靠组播传输,相关技术中IETF(The InternetEngineering Task Force,国际互联网工程任务组)提出了一种基于NACK(NegativeAcknowledge,否定确认)机制的可靠组播协议NORM(NACK-Oriented Reliable MulticastTransport Protocol),其主要的思想是,在正常情况下,发送端基于UDP+FEC方式协议封装传输数据,以组播发送,接收端接收原始数据和FEC纠错数据,并且根据报文的序号进行丢包检测,如果没有丢包,则进行FEC纠错、解码和业务呈现;如果存在丢包,那么接收端向发送端发送NACK(否定确认)报文,以此将丢失的组播报文的序号告诉发送端,发送端则根据NACK请求中的丢包报文序号,对指定的原始数据报文或者FEC纠错报文发送修复报文,接收端接收到修复报文,则进行数据重组,这样来实现可靠的数据传输。
NORM可靠组播传输方案与UDP组播+FEC纠错传输方案相比,引入了类似于TCP(Transport Control Protocol)的丢包重传和拥塞控制机制,在传输可靠性上,远远好于UDP组播+FEC方案,使得NORM可以适用于更多的传输场景。目前可以适用NORM的业务场景有:比如IPTV直播、OTT(Over The Top)直播、数字视频广播(Digital VideoBroadcasting,DVB)直播、分布式消息队列、文件分发、网红直播、视频会议、网络游戏、军事指挥系统等等。著名的开源消息队列ZeroMQ就支持使用NORM作为传输协议,CableLabs的IPTV规范也将NORM定义为媒体传输的标准协议,其市场价值越来越高。
NORM的可靠组播传输机制也存在问题,如附图1所示,图1是本发明相关技术中NORM可靠组播传输机制的示意图。
如果NORM发送端与接收端之间,发生关键传输设备的异常或者抖动,大量的接收端会同时检测到丢包,而向发送端发送大量相同丢包报文序号的NACK,形成消息风暴,NORM发送端存在处理性能瓶颈。同时NORM协议要求发送端需要具有NACK一定延迟的修复窗口,即发送端需要在一段时间窗内,收集来自不同的接收端的NACK报文,进行去重处理后,然后对丢包报文的并集,发送修复报文。为了尽可能的避免发送重复的修复报文,发送端需要设置比较长的时间窗来处理NACK报文,这样拖延了修复报文发出的时间。对于接收端来说,丢包报文修复的延迟比较大,这容易导致业务质量下降,典型地,在视频业务场景,容易导致终端上的视频画面花屏或者跳帧,影响观影体验。随着接收端数量的增加,这个问题越发明显。NORM传输机制的这个特点,导致一个NORM发送端可以支撑的接收端的数量受到限制,无法支撑IPTV/OTT等大规模用户的场景。
针对相关技术中存在的上述问题,目前尚未发现有效的解决方案。
发明内容
本发明实施例提供了一种报文传输方法及装置、系统、存储介质、电子装置。
根据本发明的一个实施例,提供了一种报文传输方法,包括:接收第一设备发送的丢失报文的序号,其中,所述丢失报文的序号用于指示在第二设备发送给所述第一设备的报文中丢失报文的序号;对所述丢失报文的序号进行去重操作,得到丢失报文序号集合;将所述丢失报文序号集合发送给所述第二设备。
根据本发明的另一个实施例,提供了一种报文传输装置,包括:接收模块,用于接收第一设备发送的丢失报文的序号,其中,所述丢失报文的序号用于指示在第二设备发送给所述第一设备的报文中丢失报文的序号;处理模块,用于对所述丢失报文的序号进行去重操作,得到丢失报文序号集合;发送模块,用于将所述丢失报文序号集合发送给所述第二设备。
根据本发明的又一个实施例,提供了报文传输系统,包括一个或多个第一设备、第二设备、过滤设备,其特征在于,其中,所述第一设备,用于接收所述第二设备发送的原始报文,以及在对所述原始报文进行丢包检测确定存在丢失报文时,将所述丢失报文的序号发送给所述过滤设备;所述过滤设备包括:接收模块,用于接收第一设备发送的丢失报文的序号,其中,所述丢失报文的序号用于指示在第二设备发送给所述第一设备的报文中丢失报文的序号;处理模块,用于对所述丢失报文的序号进行去重操作,得到丢失报文序号集合;发送模块,用于将所述丢失报文序号集合发送给所述第二设备;所述第二设备,用于向所述第一设备发送原始报文,以及接收所述丢失报文序号集合。
根据本发明的又一个实施例,还提供了一种存储介质,所述存储介质中存储有计算机程序,其中,所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
根据本发明的又一个实施例,还提供了一种电子装置,包括存储器和处理器,所述存储器中存储有计算机程序,所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。
通过本发明,通过对丢失报文的序号进行去重操作,减少相同丢失报文的序号的个数然后发送给第二设备,避免在第二设备上形成消息风暴,解决了相关技术中处理丢失报文时间太长的技术问题,减少了第二设备对丢失报文的序号的筛选工作量,进而提高了第二设备针对丢失报文发送修复报文的效率,降低了第一设备修复丢失报文的时延。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是本发明相关技术中NORM可靠组播传输机制的示意图;
图2是根据本发明实施例的报文传输方法的流程图;
图3是根据本发明实施例的报文传输装置的结构框图;
图4是根据本发明实施例的报文传输系统的结构框图;
图5是本实施例的可靠组播通讯的示意图;
图6是本实施例的一种可靠组播通讯的系统的工作原理图;
图7是本实施例的一种可靠组播通讯的实现方法流程图;
图8是本实施例的一种可靠组播NACK过滤装置内部结构图;
图9是实施场景一的可靠组播消息分发的系统结构图;
图10是实施场景一的可靠组播消息分发的流程图;
图11是本实施场景二的基于NORM的OTT直播业务系统结构图;
图12是本实施场景二的基于NORM的OTT直播内容分发的流程图;
图13是本实施场景三的基于NORM的IPTV直播系统结构图;
图14是本实施场景三的基于NORM的IPTV直播业务流程图;
图15是本实施场景四的多级NORM过滤装置系统结构图;
图16是本实施场景四的多级NORM过滤装置消息业务流程图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。
需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。
实施例1
本申请实施例可以运行的网络架构包括:一个或多个第一设备、第二设备,其中,第一设备与第二设备之间进行交互,第二设备向第一设备发送业务报文或原始报文,第一设备接收到业务报文或原始报文后,检测在传输过程中的丢失报文,或者是未接收到的丢失报文,向第二设备发起反馈过程。
在本实施例中提供了一种运行于上述网络架构的报文传输方法,图2是根据本发明实施例的报文传输方法的流程图,如图2所示,该流程包括如下步骤:
步骤S202,接收第一设备发送的丢失报文的序号,其中,丢失报文的序号用于指示在第二设备发送给第一设备的报文中丢失报文的序号;
步骤S204,对丢失报文的序号进行去重操作,得到丢失报文序号集合;
步骤S206,将丢失报文序号集合发送给第二设备。
通过上述步骤,通过对丢失报文的序号进行去重操作,减少相同丢失报文的序号的个数然后发送给第二设备,避免在第二设备上形成消息风暴,解决了相关技术中处理丢失报文时间太长的技术问题,减少了第二设备对丢失报文的序号的筛选工作量,进而提高了第二设备针对丢失报文发送修复报文的效率,降低了第一设备修复丢失报文的时延。
可选地,上述步骤的执行主体可以为服务器,功能模块等,可以设置在第一设备与第二设备的通信链路之间,或者是集成在第二设备上,但不限于此。去重操作可以删除重复的丢失报文的序号,去重操作后的序号总数少于去重操作前的序号总数,如去重操作前序号1,序号2,序号3分别为5,2,3个,去重操作后,序号1,序号2,序号3可能分别只存在2,1,2个,总数较之前的10个少了5个,在一个特例中,去重操作后,序号1,序号2,序号3可能分别只存在1,1,1个,不管怎样去重,序号1,序号2,序号3都至少存在一个。
在本实施例中,丢失报文包括:在第二设备发送报文后,第一设备在预定时间内未接收到的报文。当然也可以是在解码失败需要重新接收的报文。
可选地,第二设备根据丢失报文序号集合所指示的丢包报文,向第一设备发送修复报文,其中修复报文的序号来自丢失报文序号集合中其中一个。
可选的,在将丢失报文序号集合发送给第二设备之后,还包括:第二设备向第一设备发送修复报文,其中,修复报文为丢失报文序号集合中的序号所指示的报文。第二设备向第一设备发送原始报文,其中原始报文包含不重复的序号,第一设备根据原始报文的序号检测丢包确定丢失报文,第一设备发送的丢包报文的序号,即为第一设备检测到的丢包的原始报文的序号。
可选的,接收第一设备发送的丢失报文的序号包括:接收来自一个或多个第一设备发送的NACK报文,其中,NACK报文携带丢失报文的序号。
可选地,接收第一设备发送的丢失报文的序号包括:接收第一设备发送的NACK报文,其中,NACK报文携带丢失报文的序号。在将丢失报文序号集合发送给第二设备时,丢失报文序号集合中的丢失报文序号也可以是携带在NACK报文集合的NACK报文中。
可选地,NACK报文包括:基于可靠组播通讯协议NORM的NACK报文。
可选地,第一设备与第二设备之间传输的报文可以是组播报文或单播报文,丢失报文包括以下至少之一:组播报文,单播报文。
可选地,对丢失报文的序号进行去重操作,得到丢失报文序号集合,包括以下两种策略:
在预定时间周期内接收的全部丢失报文的序号中,将存在重复的序号进行去重,不重复的序号保留,得到丢失报文序号集合;
根据在预定时间内已经发送过的历史丢包序号列表,在接收的全部丢失报文的序号中,选择序号不包括在历史丢包序号列表中的丢失报文的序号,得到丢失报文序号集合。
可选地,在将丢失报文序号集合发送给第二设备包括以下之一:将所述丢失报文序号集合发送给所述第二设备,然后接收第二设备反馈的ACK信息,其中,ACK信息用于指示第二设备接收到丢失报文序号集合;根据预设重发次数将丢失报文序号集合发送给第二设备。如可以发送三次,保证第二设备可以接收到丢失报文序号集合,第二设备在接收到丢失报文序号集合后,也可以进行去重操作。
可选地,接收第一设备发送的丢失报文的序号包括:接收第一设备在对应的第一区域发送的丢失报文的序号。可以按照第一设备的位置划分多个区域,在每个区域上增加一个过滤装置进行过滤去重,每个过滤装置负责接收区域内第一设备的丢失报文的序号。所述丢失报文序号集合可以携带在基于NORM的NACK报文中。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
实施例2
在本实施例中还提供了一种报文传输装置、系统,用于实现上述实施例及优选实施方式,已经进行过说明的不再赘述。如以下所使用的,术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现,但是硬件,或者软件和硬件的组合的实现也是可能并被构想的。
图3是根据本发明实施例的报文传输装置的结构框图,如图3所示,该装置包括:
接收模块30,用于接收第一设备发送的丢失报文的序号,其中,丢失报文的序号用于指示在第二设备发送给第一设备的报文中丢失报文的序号;
处理模块32,用于对丢失报文的序号进行去重操作,得到丢失报文序号集合;
发送模块34,用于将丢失报文序号集合发送给第二设备。
可选的,接收模块包括:接收单元,用于接收来自一个或多个第一设备发送的NACK报文,其中,所述NACK报文携带所述丢失报文的序号。
可选的,处理模块包括以下之一:第一处理单元,用于在预定时间周期内接收的全部丢失报文的序号中,将存在重复的序号进行去重,得到丢失报文序号集合;第二处理单元,用于根据在预定时间内已经发送过的历史丢包序号列表,在接收的全部丢失报文的序号中,选择序号不包括在历史丢包序号列表中的丢失报文的序号,得到丢失报文序号集合。
图4是根据本发明实施例的报文传输系统的结构框图,如图4所示,包括:第一设备40、过滤设备42、第二设备44。
第一设备40,用于接收第二设备发送的原始报文,以及在对原始报文进行丢包检测确定存在丢失报文时,将丢失报文的序号发送给过滤设备;
第二设备44,用于向第一设备发送原始报文,以及接收丢失报文序号集合;
过滤设备42包括:接收模块30,用于接收第一设备发送的丢失报文的序号,其中,丢失报文的序号用于指示在第二设备发送给第一设备的报文中丢失报文的序号;处理模块32,用于对丢失报文的序号进行去重操作,得到丢失报文序号集合;发送模块34,用于将丢失报文序号集合发送给第二设备。
可选的,第二设备还包括:重发模块,用于向第一设备重发修复报文,其中,修复报文为丢失报文序号集合中的序号所指示的报文。
可选的,第一设备还包括:纠错模块,用于接收修复报文,并使用修复报文对数据进行纠错还原处理,以得到完整的原始报文。
可选的,重发模块还包括:第一重发单元,用于确定一个或多个第一设备中每个第一设备所丢失的报文;将修复报文中与所丢失的报文相同的报文发送给对应的第一设备;第二重发单元,用于将修复报文发送给所有的第一设备。仅发送每个第一设备所丢失的报文,目标报文在第一设备上不用再次筛选,可以减小第一设备的工作量。将所有修复报文都发送给所有第一设备,第一设备根据需要在选择修改报文,可以减小第二设备的工作量,因为不用查询每个修复报文所对应的第一设备。
需要说明的是,上述各个模块是可以通过软件或硬件来实现的,对于后者,可以通过以下方式实现,但不限于此:上述模块均位于同一处理器中;或者,上述各个模块以任意组合的形式分别位于不同的处理器中。
实施例3
本实施例是本发明的可选实施例,用于结合具体的场景示例对本申请进行详细说明:
图5是本实施例的可靠组播通讯的示意图,如附图5,通过在发送端与接收端之间增加NACK过滤装置来解决的延迟和性能问题,使得能够更好地应用于海量用户的业务场景。本实施例通过在发送端与接收端之间设立过滤装置,可以按照接收端的位置划分多个区域,在每个区域上增加一个NACK报文过滤装置,每个过滤装置负责接收区域内终端装置的NACK报文;接收端接收发送端的组播数据报文,根据组播数据报文的序号检测丢包,如果有丢包,则给该区域的过滤装置发送NACK报文,携带丢失数据包的序号;过滤装置收集该区域内的终端的NACK报文,根据NACK报文中的携带的序号进行去重,得到本区域的接收端丢包的报文序号,并向发送端发送少量的NACK报文;发送端收集不同区域的过滤装置发送的少量NACK报文,然后给所有的接收端重传丢失的报文。
本实施例提供了一种可靠组播通讯系统,如图6,图6是本实施例的一种可靠组播通讯的系统的工作原理图,包含发送端、一个或者多个过滤节点、多个数据设备、多个接收端。
发送端:可靠组播的发送源,可以是消息服务器、文件服务器、视频源站、网站服务器、中心控制系统等等。发送端需要支持NORM协议,可以创建NORM群组会话,能够将消息、文件和实时流等数据封装成IP/UDP/RTP等原始数据和FEC纠错数据。发送端能够给每个原始数据、FEC纠错数据生成报文序号,并且顺序将报文以组播方式发送给接收端。发送端支持接收过滤节点发送的NACK报文,并且在一定的时间窗内,收集不同区域的NACK报文,能够按照NACK报文中的丢包报文的序号进行去重,获得接收端丢包报文的序号列表,最后,发送端可以根据这个丢包报文的序号列表,将接收端丢失的报文重新在同一个NORM群组会话中发送。可选地,根据发送端的类型的不同,发送还支持发送NORM_CMD(包括但不限于CC、EOT、SQUELCH、REPAIR_ADV、FLUSH,参考RFC 5740)。本实施例中描述的NORM协议是以RFC 5740为例说明的,而在实际的应用中,NORM规范会更新,本实施例提出的装置、方法和系统同样是适用于RFC NORM协议的后续版本的,基于NORM新的版本使用本实施例,同样属于权利保护范围之内。
过滤装置:用来实现对接收端的NACK请求的收集和过滤。过滤装置在区域内接收本区域所有接收端的单播或者组播NACK报文,并且可以采用时间窗聚集过滤模式以及缓存转发模式,能够对NACK报文中的丢包报文序号进行去重,得到本区域所有接收端的丢失报文序号集合,并且可以将丢失的报文序号放在新的NACK报文中发送给发送端。过滤装置对于接收到的多个NACK报文中包含的每个丢包报文序号,可以采用一定的冗余策略,通过一个或者多个NACK报文发送给发送端,但每个丢包报文序号,过滤装置发给发送端的次数要小于接收的次数。可选地,过滤装置还可以将的NACK报文进行单播到组播或者是组播到单播的转换之后,再发送给发送端。过滤装置的形态可以是数据设备上的软件模块,也可以是消息代理服务器、文件分发服务器、实时流中继服务器、CDN节点、数据设备上的特殊模块、SDN控制器+SDN转发设备等等,在部署上可以是一级部署:按照地域位置,将不同地域位置的接收端划分成不同区域,每个区域部署一个;或者是多级部署,即根据接收端的数量,数据设备组网,在网络的中心和边缘都部署,形成级联。
其中,冗余策略之一,在过滤装置与上级实体之间扩展NORM信令,具体可以参考NORM协议NORM_INFO消息,对于过滤装置发送的每个NACK报文,再返回一个ACK消息,过滤装置对过滤之后的丢包报文序号,发送NACK报文之后,确认上级实体反馈NACK报文的ACK之后,才不再重传向上级实体重复发送包含该丢包报文序号的NACK报文,否则重发N(可配置)次。冗余策略之二,过滤装置设置一定的重发次数M(可配置),对于经过过滤去重之后的丢包报文序号,每个序号在过滤装置发送给上级实体的NACK报文中出现M次。
数据设备:分成2种,组播复制装置,以及组播路由网络。组播复制装置可以分成多级部署,与发送端相连的组播复制装置主要是用来发送端发出的组播报文,并且复制成多份,发送给下级组播复制装置,直到将组播报文发送到所有的接收端。组播路由网络为支持转发单播和组播报文的交换机和路由器组成的网络,在实际应用中,可以根据需要,在发送端、过滤装置和接收端之间部署多个甚至是多级数据设备。
接收端:分散在网络各个区域,支持使用NORM协议接收原始数据以及FEC纠错数据的组播报文。在接收来自发送端的NORM组播数据报文时,可以按照组播数据包中的序号,来检测是否有数据报文丢失,如果有数据报文丢失的时候,接收端可以向过滤节点发送NACK报文,并在NACK报文中包含所丢包报文的序号列表;接收端可以接收发送端发送的重传修复报文,并且可以使用修复报文进行数据还原。可选地,接收端还可以接收发送端发送的NORM_CMD(包括但不限于CC、EOT、SQUELCH、REPAIR_ADV、FLUSH,参考RFC 5740)并且做响应处理。接收端在能够对NORM传输的三种对象(消息、文件以及实时流)进行对应的业务呈现,业务呈现的方式包括大不限于消息展示、文件下载、音视频播放等等。接收端的形态可以是支持NORM标准协议的消息客户端、文件客户端、代理服务器、网络设备、电脑、手机等等。
本实施例提供了一种可靠组播通讯的实现方法,图7是本实施例的一种可靠组播通讯的实现方法流程图,如附图7,包括:
发送端初始化配置NORM群组会话的组播地址和端口:
发送端创建NORM群组会话,其中群组会话使用步骤1中定义的组播地址和端口;
多个接收端按照以下过程加入群组通信会话:
接收端初始化配置NORM群组会话的组播地址和端口,其中组播地址和端口与发送端创建的群组会话的组播地址和端口相同;
可选地,接收端初始化配置本区域的过滤装置地址信息,用于后续向此过滤装置发送单播NORM_NACK报文;
接收端根据步骤3中配置的组播地址和端口,加入NORM群组会话,并且开始在会话中接收NORM组播数据报文NORM_DATA,以及指令NORM_CMD(包括但不限于CC、EOT、SQUELCH、REPAIR_ADV、FLUSH);
可选地,发送端可以周期性地在群组会话中以组播发送NORM_CMD(FLUSH)指令,通知所有的接收端,发送准备接收NACK报文;
NORM组播数据包发送过程包括:
发送端在上述群组会话中,将需要传输的数据使用UDP封装原始数据报文,可选地,发送端还根据冗余策略,将需要传输的数据进行FEC编码,按照一定的顺序,生成NORM数据包序号,并且按照序号发送NORM组播数据报文,报文的类型为NORM_DATA,根据NORM协议的定义,可以是数据、文件或者实时流,每个NORM的数据包包含对应的序号;发送端在发送NORM组播数据报文的时候,原始数据,以及FEC纠错数据,可以是在一个NORM_DATA消息中,也可以分成不同的NORM_DATA消息。
接收端开始接收NORM组播数据报文,接收端根据NORM组播数据报文的序号进行检测丢包,组播数据报文序号具体参考RFC 5740中NORM_DATA消息格式定义;
接收端对于丢失的组播数据报文,生成NORM_NACK报文,NACK报文中包含丢失组播数据报文的序号,接收端向本区域内的过滤装置发送NORM NACK报文,其中NACK报文可以单播方式(使用步骤4中初始化的过滤装置地址),也可以是组播方式(使用上述步骤中初始化的NORM组播会话地址),丢包报文的序号放在NORM_NACK的载荷中,具体参考RFC 5740NORM_NACK的定义。
过滤装置NACK过滤、去重、转换和转发过程包括:
过滤装置在长度为N的时间窗段内,接收本区域不同接收端的NACK报文;该步骤中,N的特点是,比较小;
过滤装置根据不同的接收端发送的NACK报文的丢包报文的序号列表,进行去重;
过滤装置将去重后的NACK报文,以单播或者组播的方式转发给发送端。该步骤中,NACK报文序号列表,为在该时间窗段内,本区域所有接收端的NACK报文中序号列表的并集的子集。
发送端发送修复报文过程包括:
发送端在长度为M的时间窗内,接收不同的过滤装置的NACK报文;
发送端根据过滤装置发送的NACK报文中发送端丢失的组播数据报文的序号,进行去重,得到整个系统中所有接收端丢包报文的序号集合;
发送端对于接收端丢失的组播数据报文,修复报文的序号与NACK报文中携带的丢失组播报文的序号相同,格式与对应序号的组播数据报文格式相同,发送端在上述的群组会话中,重传修复报文,重传报文格式依旧是NORM_DATA,具体参考RFC 5740。
接收端进行数据修复过程包括:
接收端对于每个接收到的发送端发送的NORM_DATA修复报文,判断修复报文中的序号,是否是该接收端丢失的组播数据包。如果是,则使用该NORM_DATA修复报文进行数据还原;如果不是,则接收端丢弃该NORM_DATA修复报文;
接收端对于还原后的完整NORM组播数据报文进行其他处理,做业务呈现,业务呈现的形式包括但不限于,媒体播放、文件下载、消息分发。
对于有边界的数据,发送端、过滤装置、接收端反复执行步骤07~17,直到数据发送完成;
对于无边界的数据,比如实时流,可选地,接收端可以在任何时刻加入群组会话,发送端可以一直不关闭会话,持续发送NORM数据包;对于有边界的数据,比如消息和文件,发送端和接收端之间,在数据发送完成之后,还包含一个会话关闭过程:
可选地,对于有边界的数据,发送端发送NORM_CMD(EOT)指令,通知所有的接收端,传输完成;
接收端对NORM_EOT指令进行响应,等待传输完成后,退出群组会话,返回NORM_ACK;
发送端等所有的客户端都返回NORM_ACK之后,关闭群组会话。至此,附图7的流程结束。
本实施例提供了一种NORM NACK过滤装置,图8是本实施例的一种可靠组播NACK过滤装置内部结构图,如图8所示,所述NORM过滤装置,包括:
发送模块101,将过滤以及转换之后的NACK报文发送给上级实体,发送的NACK报文的格式由过滤模块过滤去重得来;
转换模块102,可选模块,用于将经过过滤去重之后的NACK报文进行单播转组播、或者是组播转单播的处理;
过滤模块103,对于接收到的多个NACK报文,根据NACK报文的丢包报文的序号,进行过滤去重;
接收模块104,用于接收来自下级实体的单播或者组播NACK报文;
使用本实施场景的方案,在各个区域都有部署NACK过滤装置,在大量的接收端检测到丢包时,接收端发送的NACK报文,先经过NACK过滤装置过滤和去重,在一个区域内,不同的终端都是丢失相同的数据包,因此区域内的NACK过滤装置处理过的NACK报文会大大减少,对于发送端来说,只是收集不同区域的NACK过滤装置发送的少量NACK报文,发送端不会接收到NACK报文风暴,发送端的性能处理要求大大降低。对发送端的NACK报文处理性能要求,更多的是与发送直接相关的过滤装置的数量,接收端的数量的增加不直接增加发送端的性能要求,采用本实施例的系统、装置和方法后,在同一个NORM会话中,接收端的数量可以大大提升。由于NACK过滤装置只接收到该区域的接收端的NACK报文,数量可控,因此NACK过滤装置可以使用很短的时间窗来收集NACK报文,接收端的NACK随机退避时长可以很小,而发送端同样因为只接收到少量NACK报文,没有性能瓶颈,也可以使用很小的时间窗来收集NACK报文,因此发送端可以更快地发出修复报文,接收端则可以尽快地接收到NORM修复报文,从而降低接收端的延迟。
本实施例可以从业务场景、部署位置上来展开成不同的应用场景。
业务场景上看,NORM有三种主要的类别,消息、文件和实时流。消息业务场景主要有:聊天室、实时消息推送、军事指挥系统等等(实施场景一);文件业务场景有IPTV点播、OTT点播、OTT直播、互联网内容分发等等(实施场景二);实时流的业务场景有IPTV直播、DVB直播、视频会议、全球眼监控、网红直播等等(实施场景三)。
从部署上看,过滤装置的位置,可以在发送端所在的网络中心,也可以是和接收端一起分散不同的网络边缘,也可以多层部署,比如,网络中心和网络边缘都存在过滤装置。NORM过滤装置接收接收端的NACK报文,可以是单播方式,也可以是组播方式,对于接收端发送的组播NACK报文,NORM过滤装置在去重之后,还可以转换成单播方式,转发给发送端,以支持长距离部署场景。实施场景四展示了2级过滤装置,并且进行了NACK的组播到单播的转换。下面分别进行详细说明:
实施场景一
使用NORM组播进行消息进行分发,消息组播报文不带FEC编码,发送端收到NACK后直接重传原始数据包,所有接收端同步接收所有的消息,并且展示。
图9是实施场景一的可靠组播消息分发的系统结构图,如附图9,本实施场景中:部署1个消息服务器,作为本发明中的NORM发送端;设立一个中间服务器,作为本发明中提出的NACK过滤装置;设立2个消息客户端(1和2),用作本发明中的NORM接收端,消息发送的组播地址为221.1.1.1:8080;在用户网络边缘的区域内部署1个组播路由器,作为组播复制装置。
图10是实施场景一的可靠组播消息分发的流程图,如附图10,消息分发流程交互如下:
701.消息服务器使用组播地址norm://221.1.1.1:8080创建群组会话;
702.消息客户端1以组播地址norm://221.1.1.1:8080加入群组会话;
703.消息客户端2以组播地址norm://221.1.1.1:8080加入群组会话;
704.消息服务器以NORM_DATA对象封装消息数据,NORM_DATA的类型是NORM_OBJECT_DATA,发送10个消息Message(1~10),消息NORM序号分别是1~10,在发送过程中,Message4~5由于网络异常导致消息客户端1丢包,Message5~6由于网络异常导致消息客户端2丢包,其他序号的包都正常发送和接收,消息客户端1和消息客户端2对于正常的包都做展示处理。
705.消息客户端1检测到丢包,向中间服务器以组播方式发送一个NORM NACK报文NACK1,NACK1包含丢包序号4和5;
706.消息客户端2检测到丢包,向中间服务器以组播方式发送一个NORM NACK报文NACK2,NACK2包含丢包序号5和6;
707.中间服务器在10ms的时间窗口内,收集到NACK1和NACK2以后,对其中的序号进行去重,取并集,得到序号并集,得到消息客户端1和消息客户端2丢包并集是4,5,6,然后中间服务器给消息服务器发送NACK3,NACK3中消息载荷中包含序号4,5,6;
708.消息服务器,收到NACK3,取得消息客户端1和2丢包的包是4,5,6,则重新发送三个原始数据报文Message4、Message5和Message6;
709.消息客户端1收到Message4、Message5、Message6,则使用重传的Message4和Messag5进行展示,则丢弃重传的Message6,使用第一次厚道的Message6进行展示。
710.消息客户端2收到Message4、Message5、Message6,则丢弃重传的Message4,使用第一次收到的Message4,以及重传的Message5和Message6进行展示。
711.等到所有的Message发送并且展示完成后,消息客户端1关闭NORM群组会话;
712.等到所有的Message发送并且展示完成后,消息客户端2关闭NORM群组会话;
713.消息服务器关闭NORM群组会话。
实施场景二
将一个文件分发到多个区域的机顶盒终端,说明在文件分发的业务应用中如何实施本发明。
图11是本实施场景二的基于NORM的OTT直播业务系统结构图,如附图11所示的OTT业务系统,本实施场景中:部署1个HLS内容源站,作为本发明中的NORM发送端;设立一个CDN节点,具备本发明中提出的NACK过滤装置功能;设立2个机顶盒客户端端(1和2),具备本发明中的NORM接收端功能。在用户网络边缘的区域内部署1个组播路由器,作为组播复制装置。HLS内容源站需要将一个视频文件列表File01~10.ts,推送到所有的机顶盒终端上播放。对于每个视频文件01~10.ts,HLS内容源站循环采用下面的步骤知道所有的视频文件传输并且播放完成。在本实施场景中,我们详细描述其中一个文件的组播分发过程,并且假设第一个文件01.ts,编码成300个NORM组播包FilePack001~300,由于中间数据设备异常,导致机顶盒1和机顶盒2同时对丢失的FilePack011~020产生NACK报文NACK1和NACK2,NACK1和NACK2中包含的丢包序号列表为11~20,以此说明。
图12是本实施场景二的基于NORM的OTT直播内容分发的流程图,如附图12,视频文件分发流程交互如下:
901.HLS内容源站创建NORM群组会话,组播地址是norm://221.1.1.1:8080;
902.机顶盒1以norm://221.1.1.1:8080加入NORM群组会话;
903.机顶盒2以norm://221.1.1.1:8080加入NORM群组会话;
HLS内容源站、CDN节点和机顶盒,重复使用步骤804到7xx视频文件直到所有的文件File01~10.ts播放完成。
904.HLS内容源站以NORM_DATA对象封装视频内容01.ts内容,编码成300个NORMDATA数据包File Pack(001~300),NORM消息序号分别是1~300,NORM_DATA的类型是NORM_OBJECT_FILE,其他序号的包都正常发送和接收,机顶盒1和机顶盒2对于正常的包都做展示处理。
905.机顶盒1检测到FilePach011到FilePack020丢包,向CDN节点以组播方式发送一个NACK报文NACK1,NACK1载荷中包含10个丢包序号11~20;
906.机顶盒2检测到FilePach011到FilePack020丢包,向CDN节点以组播方式发送一个NACK报文NACK1,NACK1载荷中包含10个丢包序号11~20;
907.CDN节点在10ms的时间窗内收集到NACK1和NACK2以后,对其中的序号进行去重,取并集,得到序号并集,得到机顶盒1和机顶盒2丢包并集是11~20,然后中间服务器给HLS内容源站发送NACK3,NACK3中消息载荷中包含10个序号11~20;
908.HLS内容源站,收到NACK3,取得机顶盒1和2丢包的包是11~20,则重新发送10个包的组播修复报文FilePack010~020,分别是FilePack011~020的修复报文;
909.机顶盒1收到FilePack011~020,则开始进行数据修复,然后则转换成视频画面,继续播放File01.ts,直到播放完成。
910.机顶盒2收到FilePack011~020,则开始进行数据修复,然后则转换成视频画面,继续播放File01.ts,直到播放完成。
911.等到所有的Message发送并且展示完成后,机顶盒1关闭群组会话;
912.等到所有的Message发送并且展示完成后,机顶盒2关闭群组会话;
913.HLS内容源站关闭群组会话。
实施场景三
以NORM的实时流对象说明,如何在无边界的实时流业务中实施本发明。
图13是本实施场景三的基于NORM的IPTV直播系统结构图,如附图13所示的IPTV直播业务系统,本实施场景中:部署1个直播编码器,作为本实施例中的NORM发送端;设立一个CDN节点,具备本发明中提出的NACK过滤装置功能;设立2个机顶盒客户端端(1和2),具备本发明中的NORM接收端功能。在用户网络边缘的区域内部署1个组播路由器,作为组播复制装置。直播编码器向所有的机顶盒推送H.264直播流,直播流以H.264方式编码,并且使用8%的FEC冗余度,FEC纠错数据随NORM原始数据一起发送,直播编码器采用统一的NORM_DATA封装原始数据编码和FEC编码,序号统一生成。直播源在07:00分开始创建NORM会话,初始视频组播报文的序号是1,机顶盒1在07:05分加入NORM会话接收组播,开始观看视频,接收第一个组播报文的序号是30000。机顶盒2在07:10分加入NORM会话接收组播,开始观看视频,接收到的第一个组播报文序号是60000。直播编码器循在07:15分由于网络原因导致丢包50个,丢包报文的序号从90000~90050,对应的组播报文为Stream90000~90050.机顶盒1和机顶盒2同时在07:15分同时产生NACK1和NACK2,NACK1和NACK2中均包含丢包序号列表90000~90050。
图14是本实施场景三的基于NORM的IPTV直播业务流程图,如附图14所示的IPTV直播业务系统的交互流程如下:
1101.直播编码器以组播地址norm://224.1.1.1:8080创建群组会话;
1102.07:00:00开始,直播编码器对产生组播直播流,直播流的基于NORM_DATA格式封装,NORM对象类型为NORM_OJECT_STREAM,NORM_DATA包含原始数据和FEC编码数据,以每秒100个组播报文速度发送,每个组播报文生成一个NORM_DATA序号,从0开始,序号为x的报文为Streamx。
1103.07:05:00开始,机顶盒1以组播地址norm://224.1.1.1:8080加入NORM群组会话,并且开启一个缓存区,存放5秒以内接收到的组播直播流报文;
1104.机顶盒1开始组播报文序号30000开始接收组播直播流,解析NORM_DATA,获取到原始数据以及FEC编码数据,然后进行FEC解码,视频播放开始。
1105.07:10:00开始,机顶盒2以组播地址norm://224.1.1.1:8080加入NORM群组会话,并且开启一个缓存区,存放5秒以内接收到的组播直播流报文;
1106.机顶盒2开始组播报文序号60000开始接收组播直播流,解析NORM_DATA,获取到原始数据以及FEC编码数据,然后进行FEC解码,视频播放开始。
1107.07:15:00,机顶盒1检测到缓存区中序号为90000~90050的组播直播流报文未接收到,向CDN节点以组播方式发送一个NACK报文NACK1,NACK1载荷中包含丢包序号范围90000~90050;
1108.07:15:00,机顶盒2检测到缓存区中序号为90000~90050的组播直播流报文未接收到,向CDN节点以组播方式发送一个NACK报文NACK2,NACK2载荷中包含丢包序号范围90000~90050
1109.CDN节点在100ms的时间窗段内,收到NACK1和NACK2以后,对其中的序号列表进行去重,取并集,得到序号并集,得到机顶盒1和机顶盒2丢包并集是90000~900500,然后CDN节点给直播编码器发送NACK3,NACK3中消息载荷中包含序号范围90000~90050;
1110.直播编码器在100ms的时间窗段内,收到NACK3,取得机顶盒1和2丢包的包是90000~90050,则重新发送序号为90000~90050的组播直播流报文,Stream90000~Stream90050;
1111.机顶盒1收到Stream90000~Stream90050,补齐缓冲区中对应的数据包,等到机顶盒视频播放达到Stream90000时,然后重新解析NORM_DATA,获取到原始数据以及FEC编码数据,然后进行FEC解码,持续进行画面展示。
1112.机顶盒2收到Stream90000~Stream90050,补齐缓冲区中对应的数据包,等到机顶盒视频播放达到Stream90000时,然后重新解析NORM_DATA,获取到原始数据以及FEC编码数据,然后进行FEC解码,持续进行画面展示。
1113.机顶盒1在遥控器切换或者关闭频道时,关闭群组会话,停止接收组播直播流;
1114.机顶盒2在遥控器切换或者关闭频道时,关闭群组会话,停止接收组播直播流;
本实施场景中,只要步骤1107、1110和1111所占用的时间之和,小于机顶盒1缓冲区的长度,即可以实现视频的连续播放,机顶盒1丢视频丢包无感知。同样,只要步骤1108、1110和1112所占用的时间之和,小于机顶盒2缓冲区的长度,即可以实现视频的连续播放,机顶盒2丢视频丢包无感知。
实施场景四
多级架构下,以文件分发为例,说明如何部署多级NORM过滤装置,以支持一个NORM发送端支持的接收端的数量,同时为了防止NORM NACK报文扩散,本实施场景中区域的过滤装置上增加了组播NACK转单播的方法,使得不同区域接收端的发送的组播NACK报文,只在本区域内传播,避免了组播NACK报文对接收端的性能冲击,进一步增加本发明的实用性。
图15是本实施场景四的多级NORM过滤装置系统结构图,如图15所示,本实施场景中:部署1个消息服务器,作为本发明中的NORM发送端;设立2级NORM过滤装置,2个边缘过滤装置和1个中心过滤装置。区域1中包含消息客户端(1、2、3),区域2中包含息客户端(4、5、6),作为本发明中的接收端。每个区域中包含一个NORM过滤装置,分别是过滤装置1和过滤装置2,分别接收对应区域的消息客户端的组播NACK报文,边缘过滤装置1和2,将过滤去重之后的NACK报文转换成单播,发送给中心过滤装置3,中心过滤装置通过单播方式发送NACK报文给发送端。同时,每个区域还包含一个组播路由器,作为本发明中说明的组播复制装置。同时,为了说明本发明附属权利中提出的过滤装置的2种过滤模式,本实施场景中边缘过滤装置1和2,采用了时间窗聚集过滤模式,中心过滤装置3采用了缓存转发过滤模式,初始缓存中,已经发过NACK的丢包报文序号列表为空。
本实施场景还是采用消息类业务作为说明,出于篇幅考虑,关于消息类NORM会话创建、会话关闭的步骤请参考实施场景一,本实施场景中只列出和多级NORM过滤装置,以及NACK转换相关的步骤。本实施场景中NORM组播消息为NORM_DATA,传输对象类型为NORM_OBJECT_DATA,无FEC编码;NACK报文为NORM_NACK。NORM_DATA和NORM_NACK格式参考RFC5740。
图16是本实施场景四的多级NORM过滤装置消息业务流程图,如附图16,多级NORM过滤装置的消息业务实现流程包括:
1201,消息服务器按照顺序发送NORM组播消息Message1~10。
1202~1204三个步骤为区域1的客户端、过滤装置的工作过程;
1202,区域1的消息客户端1,2,3检测到序号4,5丢包,分别向过滤装置1发送组播NACK报文1,包含序号丢包序号4,5;
1203,过滤装置1采用时间窗聚集过滤模式,即在10ms的时间窗内,接收客户端1,2,3发送的三个组播NACK报文,按照NACK报文中携带的序号进行过滤,去重,得到区域1丢包的报文序号列表4,5;
1204,过滤装置1向过滤装置3发送单播NACK报文NACK3,NACK报文中包含序号列表4,5;
1205~1207三个步骤为区域2的客户端、过滤装置的工作过程;
1205,区域2的消息客户端4,5,6检测到序号5,6丢包,分别向过滤装置2发送组播NACK报文2,包含序号丢包序号5,6;
1206,过滤装置2采用时间窗聚集过滤模式,即在10ms的时间窗内,对客户端4,5,6发送的组播NACK2报文,按照NACK报文中携带的丢包序号进行过滤,去重,得到区域2丢包的报文序号列表5,6;
1207,过滤装置2向过滤装置3发送单播NACK报文NACK4,NACK报文中包含序号列表5,6;
区域1和区域2的2个工作过程为并行的,没有先后关系。这里我们假设,过滤装置1发送的NACK3比过滤装置2发送的NACK4先到达过滤装置3.
1208,过滤装置3采用缓存转发过滤模式,即收到过滤装置1发送的单播NACK报文NACK3后,从缓存中判断序号4,5的NACK报文未发送过,则立即向发送端发送单播NACK报文NACK5,NACK中包含丢包序号列表4,5,过滤装置3,将丢包序号4,5保存在缓存中;
1209,过滤装置3采用缓存转发过滤模式,收到过滤装置2发送的单播NACK报文NACK4后,从缓存中判断丢包序号5的NACK报文未发送过,而丢包序号6的NACK报文已经发送过,则向发送端发送单播NACK报文NACK6,NACK中只包含丢包序号列表6;过滤装置3将丢包序号6保存在缓存中;
1210,发送端收到过滤装置3发送的单播NACK报文NACK5之后,则开始重传原始组播消息Message4,5;
1211,发送端收到过滤装置3发送的单播NACK报文NACK6之后,则开始重传原始组播消息Message6;
1212,客户端1,2,3接收到发送端重传的Message4,5,则使用Message4,5进行数据还原,然后展示消息。
1213,客户端4,5,6接收到发送端重传的Message4,5,则丢弃Message4,使用Message5,还原部分数据。
1214,客户端1,2,3接收到发送端重传的Message6,则丢弃Message6。
1215,客户端4,5,6接收到发送端重传的Message6,则使用Message6还原剩余的部分数据,然后展示消息。
实施例4
本发明的实施例还提供了一种存储介质,该存储介质中存储有计算机程序,其中,该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
可选地,在本实施例中,上述存储介质可以被设置为存储用于执行以下步骤的计算机程序:
S1,接收第一设备发送的丢失报文的序号,其中,所述丢失报文的序号用于指示在第二设备发送给所述第一设备的报文中丢失报文的序号;
S2,对所述丢失报文的序号进行去重操作,得到丢失报文序号集合;
S3,将所述丢失报文序号集合发送给所述第二设备。
可选地,在本实施例中,上述存储介质可以包括但不限于:U盘、只读存储器(Read-Only Memory,简称为ROM)、随机存取存储器(Random Access Memory,简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
本发明的实施例还提供了一种电子装置,包括存储器和处理器,该存储器中存储有计算机程序,该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。
可选地,上述电子装置还可以包括传输设备以及输入输出设备,其中,该传输设备和上述处理器连接,该输入输出设备和上述处理器连接。
可选地,在本实施例中,上述处理器可以被设置为通过计算机程序执行以下步骤:
S1,接收第一设备发送的丢失报文的序号,其中,所述丢失报文的序号用于指示在第二设备发送给所述第一设备的报文中丢失报文的序号;
S2,对所述丢失报文的序号进行去重操作,得到丢失报文序号集合;
S3,将所述丢失报文序号集合发送给所述第二设备。
可选地,本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例,本实施例在此不再赘述。
显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

Claims (18)

1.一种报文传输方法,其特征在于,包括:
接收第一设备发送的丢失报文的序号,其中,所述丢失报文的序号用于指示在第二设备发送给所述第一设备的报文中丢失报文的序号;
对所述丢失报文的序号进行去重操作,得到丢失报文序号集合;
将所述丢失报文序号集合发送给所述第二设备。
2.根据权利要求1所述的方法,其特征在于,在将所述丢失报文序号集合发送给所述第二设备之后,所述方法还包括:
所述第二设备向所述第一设备发送修复报文,其中,所述修复报文为所述丢失报文序号集合中的序号所指示的报文。
3.根据权利要求1所述的方法,其特征在于,接收第一设备发送的丢失报文的序号包括:
接收来自一个或多个所述第一设备发送的NACK报文,其中,所述NACK报文携带所述丢失报文的序号。
4.根据权利要求3所述的方法,其特征在于,所述NACK报文包括:基于可靠组播通讯协议NORM的NACK报文。
5.根据权利要求1所述的方法,其特征在于,对所述丢失报文的序号进行去重操作,得到丢失报文序号集合,包括以下之一:
在预定时间周期内接收的全部所述丢失报文的序号中,将存在重复的序号进行去重,得到所述丢失报文序号集合;
根据在预定时间内已经发送过的历史丢包序号列表,在接收的全部所述丢失报文的序号中,选择序号不包括在所述历史丢包序号列表中的丢失报文的序号,得到所述丢失报文序号集合。
6.根据权利要求1所述的方法,其特征在于,将所述丢失报文序号集合发送给所述第二设备包括以下之一:
将所述丢失报文序号集合发送给所述第二设备,并接收所述第二设备反馈的ACK信息,其中,所述ACK信息用于指示所述第二设备接收到所述丢失报文序号集合;
根据预设重发次数将所述丢失报文序号集合发送给所述第二设备。
7.根据权利要求1所述的方法,其特征在于,接收第一设备发送的丢失报文的序号包括:
接收第一区域中所有所述第一设备发送的丢失报文的序号。
8.根据权利要求1所述的方法,其特征在于,将所述丢失报文序号集合发送给所述第二设备包括以下之一:
将所述丢失报文序号集合分成一次发送给所述第二设备;
将所述丢失报文序号集合拆分后,分批发送给所述第二设备。
9.根据权利要求8中所述的方法,其特征在于,所述丢失报文序号集合携带在基于NORM的NACK报文中。
10.一种报文传输装置,其特征在于,包括:
接收模块,用于接收第一设备发送的丢失报文的序号,其中,所述丢失报文的序号用于指示在第二设备发送给所述第一设备的报文中丢失报文的序号;
处理模块,用于对所述丢失报文的序号进行去重操作,得到丢失报文序号集合;
发送模块,用于将所述丢失报文序号集合发送给所述第二设备。
11.根据权利要求10所述的装置,其特征在于,所述接收模块包括:
接收单元,用于接收来自一个或多个第一设备发送的NACK报文,其中,所述NACK报文携带所述丢失报文的序号。
12.根据权利要求10所述的装置,其特征在于,所述处理模块包括以下之一:
第一处理单元,用于在预定时间周期内接收的全部所述丢失报文的序号中,将存在重复的序号进行去重,得到所述丢失报文序号集合;
第二处理单元,用于根据在预定时间内已经发送过的历史丢包序号列表,在接收的全部所述丢失报文的序号中,选择序号不包括在所述历史丢包序号列表中的丢失报文的序号,得到所述丢失报文序号集合。
13.一种报文传输系统,包括一个或多个第一设备、第二设备、过滤设备,其特征在于,其中,
所述第一设备,用于接收所述第二设备发送的原始报文,以及在对所述原始报文进行丢包检测确定存在丢失报文时,将所述丢失报文的序号发送给所述过滤设备;
所述过滤设备包括:接收模块,用于接收第一设备发送的丢失报文的序号,其中,所述丢失报文的序号用于指示在第二设备发送给所述第一设备的报文中丢失报文的序号;处理模块,用于对所述丢失报文的序号进行去重操作,得到丢失报文序号集合;发送模块,用于将所述丢失报文序号集合发送给所述第二设备;
所述第二设备,用于向所述第一设备发送原始报文,以及接收所述丢失报文序号集合。
14.根据权利要求13所述的系统,其特征在于,所述第二设备还包括:
重发模块,用于向所述第一设备重发修复报文,其中,所述修复报文为所述丢失报文序号集合中的序号所指示的报文。
15.根据权利要求14所述的系统,所述第一设备还包括:
纠错模块,用于接收所述修复报文,并使用所述修复报文对数据进行纠错还原处理,以得到完整的原始报文。
16.根据权利要求14所述的系统,所述重发模块还包括:
第一重发单元,用于确定所述一个或多个第一设备中每个第一设备所丢失的报文;将所述修复报文中与所丢失的报文相同的报文发送给对应的所述第一设备;
第二重发单元,用于将所述修复报文发送给所有的所述第一设备。
17.一种存储介质,其特征在于,所述存储介质中存储有计算机程序,其中,所述计算机程序被设置为运行时执行所述权利要求1至9任一项中所述的方法。
18.一种电子装置,包括存储器和处理器,其特征在于,所述存储器中存储有计算机程序,所述处理器被设置为运行所述计算机程序以执行所述权利要求1至9任一项中所述的方法。
CN201810443885.0A 2018-05-10 2018-05-10 报文传输方法及装置、系统、存储介质、电子装置 Active CN108616334B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201810443885.0A CN108616334B (zh) 2018-05-10 2018-05-10 报文传输方法及装置、系统、存储介质、电子装置
PCT/CN2019/085550 WO2019214550A1 (zh) 2018-05-10 2019-05-05 报文传输方法及装置、系统、存储介质、电子装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810443885.0A CN108616334B (zh) 2018-05-10 2018-05-10 报文传输方法及装置、系统、存储介质、电子装置

Publications (2)

Publication Number Publication Date
CN108616334A true CN108616334A (zh) 2018-10-02
CN108616334B CN108616334B (zh) 2020-09-29

Family

ID=63662621

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810443885.0A Active CN108616334B (zh) 2018-05-10 2018-05-10 报文传输方法及装置、系统、存储介质、电子装置

Country Status (2)

Country Link
CN (1) CN108616334B (zh)
WO (1) WO2019214550A1 (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019214550A1 (zh) * 2018-05-10 2019-11-14 中兴通讯股份有限公司 报文传输方法及装置、系统、存储介质、电子装置
CN110932934A (zh) * 2019-11-21 2020-03-27 中国联合网络通信集团有限公司 一种网络丢包的检测方法和装置
CN111885404A (zh) * 2020-07-16 2020-11-03 RealMe重庆移动通信有限公司 数据传输方法、设备及存储介质
CN113645175A (zh) * 2020-04-27 2021-11-12 北京京东乾石科技有限公司 数据通信方法、装置、设备及计算机可读存储介质
CN113992607A (zh) * 2021-09-09 2022-01-28 新华三信息安全技术有限公司 报文处理方法及装置
CN114337942A (zh) * 2021-12-29 2022-04-12 伟乐视讯科技股份有限公司 一种报文重传方法、装置及电子设备
WO2023133697A1 (zh) * 2022-01-11 2023-07-20 华为技术有限公司 丢包处理方法、装置、交换机、发送设备和数据传输系统

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114338559B (zh) * 2021-12-15 2024-03-22 杭州迪普信息技术有限公司 一种报文保序的方法及装置
CN116470991A (zh) * 2022-01-07 2023-07-21 华为技术有限公司 一种通信系统、通信方法及设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1263160A1 (en) * 2001-06-01 2002-12-04 Telefonaktiebolaget Lm Ericsson Method and transmitter for an efficient packet data transfer in a transmission protocol with repeat requests
US20030126514A1 (en) * 2001-12-27 2003-07-03 Microsoft Corporation Method and system for dynamically adjusting transmit and receive parameters for handling negative acknowledgments in reliable multicast
EP1307990B1 (en) * 2000-07-24 2006-11-29 Telefonaktiebolaget LM Ericsson (publ) Flexible arq for packet data transmission
CN105721950A (zh) * 2016-03-30 2016-06-29 浙江宇视科技有限公司 一种可靠媒体流传输装置
CN106209915A (zh) * 2016-08-31 2016-12-07 深圳聚点互动科技有限公司 一种实时流媒体无线传输方法及其系统
CN106301694A (zh) * 2016-08-11 2017-01-04 浙江宇视科技有限公司 一种减少可靠组播传输中数据包重传次数的方法及装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108616334B (zh) * 2018-05-10 2020-09-29 南京中兴软件有限责任公司 报文传输方法及装置、系统、存储介质、电子装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1307990B1 (en) * 2000-07-24 2006-11-29 Telefonaktiebolaget LM Ericsson (publ) Flexible arq for packet data transmission
EP1263160A1 (en) * 2001-06-01 2002-12-04 Telefonaktiebolaget Lm Ericsson Method and transmitter for an efficient packet data transfer in a transmission protocol with repeat requests
US20030126514A1 (en) * 2001-12-27 2003-07-03 Microsoft Corporation Method and system for dynamically adjusting transmit and receive parameters for handling negative acknowledgments in reliable multicast
CN105721950A (zh) * 2016-03-30 2016-06-29 浙江宇视科技有限公司 一种可靠媒体流传输装置
CN106301694A (zh) * 2016-08-11 2017-01-04 浙江宇视科技有限公司 一种减少可靠组播传输中数据包重传次数的方法及装置
CN106209915A (zh) * 2016-08-31 2016-12-07 深圳聚点互动科技有限公司 一种实时流媒体无线传输方法及其系统

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019214550A1 (zh) * 2018-05-10 2019-11-14 中兴通讯股份有限公司 报文传输方法及装置、系统、存储介质、电子装置
CN110932934A (zh) * 2019-11-21 2020-03-27 中国联合网络通信集团有限公司 一种网络丢包的检测方法和装置
CN113645175A (zh) * 2020-04-27 2021-11-12 北京京东乾石科技有限公司 数据通信方法、装置、设备及计算机可读存储介质
CN113645175B (zh) * 2020-04-27 2023-08-08 北京京东乾石科技有限公司 数据通信方法、装置、设备及计算机可读存储介质
CN111885404A (zh) * 2020-07-16 2020-11-03 RealMe重庆移动通信有限公司 数据传输方法、设备及存储介质
CN113992607A (zh) * 2021-09-09 2022-01-28 新华三信息安全技术有限公司 报文处理方法及装置
CN113992607B (zh) * 2021-09-09 2023-11-03 新华三信息安全技术有限公司 报文处理方法及装置
CN114337942A (zh) * 2021-12-29 2022-04-12 伟乐视讯科技股份有限公司 一种报文重传方法、装置及电子设备
WO2023133697A1 (zh) * 2022-01-11 2023-07-20 华为技术有限公司 丢包处理方法、装置、交换机、发送设备和数据传输系统

Also Published As

Publication number Publication date
CN108616334B (zh) 2020-09-29
WO2019214550A1 (zh) 2019-11-14

Similar Documents

Publication Publication Date Title
CN108616334A (zh) 报文传输方法及装置、系统、存储介质、电子装置
JP6419235B2 (ja) デジタル放送システムにおけるデータを受信する装置
KR100327791B1 (ko) 분배형 인터넷 프로토콜 기반의 실시간 멀티미디어 스트리밍 아키텍쳐
CN105530553B (zh) Rtmp与rudp结合的实时流媒体直播系统
US20080056256A1 (en) Client-server emulation supporting multicast transmissions of media objects
DE112006002644T5 (de) Mediendatenverarbeitung unter Verwendung von charakteristischen Elementen für Streaming- und Steuerprozesse
CN103780971A (zh) 一种互联网条件下基于rudp的实时视频传输方法
CN107295364B (zh) 用于弹幕视频的实时流传输控制方法、控制装置
KR20080075095A (ko) 비디오 네트워크를 관리하는 방법 및 시스템
US20100161824A1 (en) Method for transmitting of a multi-channel data stream on a multi-transport tunnel, corresponding computer-readable storage means and tunnel end-points
CN112953850B (zh) 数据传输方法、装置、计算机可读介质及电子设备
WO2015117355A1 (zh) 一种实现终端多媒体广播的方法及装置
CN110474721A (zh) 视频数据传输方法、装置及计算机可读存储介质
CN108965777B (zh) 一种回声消除方法和装置
CN111245733B (zh) 一种数据传输的方法和装置
CN108900907A (zh) 封装数据包方法及装置、电子设备、介质
JP4292884B2 (ja) リアルタイムデータ通信システム、リアルタイムデータ通信装置およびリアルタイムデータ通信方法
CN110086772B (zh) 一种监控视频的获取方法和系统
CN110691036A (zh) 一种基于视联网的数据传输方法和装置
Fuentes et al. Network coding for streaming video over p2p networks
Icart et al. Optimizations for efficient and transparent use of IP applications over HF links
Cranley et al. Quality of Service for Streamed Multimedia over the Internet
Amirante et al. SOLEIL: Streaming of Large-scale Events over Internet Clouds
Plesca et al. A coordination-level middleware for supporting flexible consistency in CSCW
Berthou et al. Multimedia multi-networking: a new concept

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20200819

Address after: 210012 Nanjing, Yuhuatai District, South Street, Bauhinia Road, No. 68

Applicant after: Nanjing Zhongxing Software Co.,Ltd.

Address before: 518057 Nanshan District science and technology, Guangdong Province, South Road, No. 55, No.

Applicant before: ZTE Corp.

GR01 Patent grant
GR01 Patent grant