CN109327398A - 一种防止丢包的方法及装置 - Google Patents
一种防止丢包的方法及装置 Download PDFInfo
- Publication number
- CN109327398A CN109327398A CN201811392076.8A CN201811392076A CN109327398A CN 109327398 A CN109327398 A CN 109327398A CN 201811392076 A CN201811392076 A CN 201811392076A CN 109327398 A CN109327398 A CN 109327398A
- Authority
- CN
- China
- Prior art keywords
- client
- packet loss
- healthy
- polling cycle
- multicast
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/16—Multipoint routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2854—Wide area networks, e.g. public data networks
- H04L12/2856—Access arrangements, e.g. Internet access
- H04L12/2869—Operational details of access network equipments
- H04L12/287—Remote access server, e.g. BRAS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0823—Errors, e.g. transmission errors
- H04L43/0829—Packet loss
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/16—Threshold monitoring
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本公开提供一种防止丢包的方法及装置,所述方法应用于BRAS设备,所述方法包括:若检测到客户端针对IGMP查询报文发送的IGMP应答报文存在丢包,则判断当前CPU使用率是否小于阈值;若是,则将所述客户端的组播表项对应的查询周期增加预设时长;若否,则增加所述客户端的组播表项对应的健壮系数;根据修改后的查询周期或健壮系数更新所述客户端的组播表项对应的老化时间,清空丢包计数,重新发送IGMP查询报文。本公开可以根据设备繁忙程度和丢包情况对老化参数进行自动调整,从而避免了大组播应用中可能出现的网络设备繁忙导致丢包和组播老化等问题。
Description
技术领域
本公开涉及通信技术领域,尤其涉及一种防止丢包的方法及装置。
背景技术
BRAS(Broadband Remote Access Server,宽带远程接入服务器)是用来完成各种宽带接入方式的宽带网络用户的接入、认证、计费、控制、管理的网络设备,是宽带网络可运营、可管理的基石。由于BRAS设备下可能存在多个IPTV(Internet Protocol Television,互联网协议电视)接入用户,当前BRAS设备下组播数据的复制方式主要采用按用户会话进行复制。由于该模式下,IGMP(Internet Group Management Protocol,互联网组管理协议)需要维护巨大的用户组播组,在BRAS设备发IGMP查询报文后会在一段时间内集中的收到大量的IGMP report(应答)报文,此时BRAS设备需要复制非常多的用户会话很容易因为处理不过来而导致丢包,造成用户的组播表项因为丢包而老化,最终导致用户收不到组播流量。
发明内容
有鉴于此,本公开提供一种防止丢包的方法及装置来解决现有技术中因丢包造成的组播老化的问题。
具体地,本公开是通过如下技术方案实现的:
本公开提供一种防止丢包的方法,所述方法应用于BRAS设备,所述方法包括:
若检测到客户端针对IGMP查询报文发送的IGMP应答报文存在丢包,则判断当前CPU使用率是否小于阈值;
若是,则将所述客户端的组播表项对应的查询周期增加预设时长;
若否,则增加所述客户端的组播表项对应的健壮系数;
根据修改后的查询周期或健壮系数更新所述客户端的组播表项对应的老化时间,清空丢包计数,重新发送IGMP查询报文。
基于相同的构思,本公开还提供一种防止丢包的装置,所述装置应用于BRAS设备,所述装置包括:
判断单元,用于若检测到客户端针对IGMP查询报文发送的IGMP应答报文存在丢包,则判断当前CPU使用率是否小于阈值;
第一增加单元,用于若CPU使用率小于阈值,则将所述客户端的组播表项对应的查询周期增加预设时长;
第二增加单元,用于若CPU使用率大于等于阈值,则增加所述客户端的组播表项对应的健壮系数;
第一更新单元,用于根据修改后的查询周期或健壮系数更新所述客户端的组播表项对应的老化时间,清空丢包计数,重新发送IGMP查询报文。
基于相同的构思,本公开还提供一种计算机可读存储介质,所述计算机可读存储介质内存储有计算机程序,所述计算机程序被处理器执行时实现防止丢包的方法的任一步骤。
基于相同的构思,本公开还提供一种计算机设备,所述计算机设备包括存储器、处理器、通信接口以及通信总线;其中,所述存储器、处理器、通信接口通过所述通信总线进行相互间的通信;
所述存储器,用于存放计算机程序;
所述处理器,用于执行所述存储器上所存放的计算机程序,所述处理器执行所述计算机程序时实现防止丢包的方法的任一步骤。
由此可见,本公开可以使BRAS设备在当前查询周期内,若检测到客户端针对IGMP查询报文发送的IGMP应答报文存在丢包时,根据CPU的繁忙程度进行适当的调整,即若CPU不繁忙,则可以通过增加查询周期时长更新老化时间;若CPU繁忙,则通过增加健壮系数更新老化时间。相比于现有技术中按照固定的老化参数进行组播表项维护,本公开可以根据设备繁忙程度和丢包情况对老化参数进行自动调整,从而避免了大组播应用中可能出现的网络设备繁忙导致丢包和组播老化等问题,解决了用户因为丢包而收不到组播流量的问题,提升了组网的灵活性,优化了组播用户体验。
附图说明
图1是本公开一种示例性实施方式中的BRAS组网示意图;
图2是本公开一种示例性实施方式中的一种防止丢包的方法的处理流程图;
图3是本公开一种示例性实施方式中的另一种防止丢包的方法的处理流程图;
图4本公开一种示例性实施方式中的防止丢包的装置的逻辑结构图;
图5本公开一种示例性实施方式中的一种计算机设备的逻辑结构图。
具体实施方式
请参考图1,为BRAS组网示意图,其中多个IPTV接入用户,例如PC1、PC2、PC3可以通过交换机连接BRAS设备,通过BRAS设备实现访问ISP(Internet Service Provider,互联网服务提供商),从而可以从ISP上获取互联网接入业务、信息业务和增值业务等。
当多个用户(例如PC1、PC2、PC3)点播同一个节目时,ISP发送单播流量到主BRAS设备,主BRAS设备发送组播流量时,会根据接入的用户复制三份单播流量。这样的按用户会话的复制方式,会导致BRAS设备需要维护巨大的用户组播表项。在BRAS设备维护组播表项过程中,BRAS设备向组播组的每个用户发送IGMP查询报文后,会在一段时间内收到大量的IGMP report应答报文,若BRAS设备处理不及时很容易造成丢包,导致在默认的查询周期下组播表项因为设备繁忙丢包而老化,最终导致用户收不到组播流量。
当前无相关技术解决该问题,如果想通过搭建模拟网络环境尝试得到理想的放大查询周期和健壮系数,但是这就要求开发人员熟知网络环境,否则模拟的网络环境如果与实际应用的网络环境稍有偏差,就会导致模拟得到的查询周期和健壮系数不准确,从而无法解决上述问题;如果一次性将查询周期和健壮系数调试得很大,又会导致BRAS组播老化时间过长,影响BRAS的运行。
为了解决现有技术存在的问题,本公开提供一种防止丢包的方法及装置,可以使BRAS设备若检测到客户端针对IGMP查询报文发送的IGMP应答报文存在丢包时,根据CPU的繁忙程度进行适当的调整,即若CPU不繁忙,则可以通过增加查询周期时长更新老化时间;若CPU繁忙,则通过增加健壮系数更新老化时间。相比于现有技术中按照固定的老化参数进行组播表项维护,本公开可以根据设备繁忙程度和丢包情况对老化参数进行自动调整,从而避免了大组播应用中可能出现的网络设备繁忙导致丢包和组播老化等问题,解决了用户因为丢包而收不到组播流量的问题,提升了组网的灵活性,优化了组播用户体验。
请参考图2,是本公开一种示例性实施方式中的一种防止丢包的方法的处理流程图,所述方法应用于BRAS设备,所述方法包括:
步骤201、若检测到客户端针对IGMP查询报文发送的IGMP应答报文存在丢包,则判断当前CPU使用率是否小于阈值;若是,转步骤202;若否,转步骤203;
在本实施例中,BRAS设备用户侧接口启用IGMP和按用户复制命令IGMP join-by-session后,开始对BRAS设备的IGMP report应答报文所经过的各个流程中进行丢包统计。由于BRAS设备本身就能够记录各种丢包情况,因此本实施例只需获取并记录IGMP report报文的丢包计数即可。在当前查询周期内,可以根据丢包计数判断客户端针对IGMP查询报文发送的IGMP应答报文是否存在丢包,如果存在,则继续获取CPU的使用率;如果不存在,则根据现有的流程转发组播流量,并等待下一个查询周期再进行检测。
如果存在丢包时,BRAS设备可以获取CPU的使用率来判断CPU是否繁忙。具体来讲,可以判断当前CPU使用率是否小于阈值,若小于,则说明CPU不繁忙;若不小于,则说明CPU繁忙。
步骤202、将所述客户端的组播表项对应的查询周期增加预设时长;
当CPU使用率小于阈值时,可以认为当前设备不繁忙,因此可以认为此时的丢包情况不严重,因此只需要将该客户端的组播表项对应的查询周期增加到预设时长,来延长当前和之后的查询周期,进而增加该客户端对应的组播表项的老化时间。举例来讲,当CPU不繁忙但是有丢包时,可以调整查询周期+10秒,因为常规的最大响应时间是10秒,调整查询时间如果小于10秒则意义不大。从而可以根据修改后的查询周期来延长组播表项的老化时间。
需要说明的是,在实际应用中,查询周期不可能无限延长,因此可以根据网络实际情况设置一个最大周期。BRAS设备在增大查询周期时,进一步需要判断所述查询周期是否大于预设最大周期,如果不大于,则可以继续增加查询周期;如果大于,则认为查询时间足够长,而网络还是存在丢包,则需要增加健壮系数,例如将该健壮系数加1,并将查询周期的时长恢复到初始值,所谓的健壮系数是用于表示系统稳定性的参数。修改健壮系数后,可以进一步修改后的健壮系数和查询周期更新所述老化时间,清空丢包计数,重新发送IGMP查询报文。
举例来讲,假设查询周期的初始值为50秒,当CPU不繁忙但是有丢包时,增加查询周期的时长,假设每次增加10秒,则当前查询周期就变为50+10=60秒,下一个查询周期也是60秒;若重复上述流程,当查询周期增加到预设最大周期(例如250秒)时,可以将健壮系数加1,而将查询周期还原到初始值,即50秒,然后根据增加的健壮系数和查询周期的初始值计算老化时间。
步骤203、增加所述客户端的组播表项对应的健壮系数;
当CPU使用率大于等于阈值时,可以认为当前设备繁忙,因此可以认为此时的丢包情况较严重,为缓解设备压力,需要增加该客户端的组播表项对应的健壮系数,例如健壮系数加1,从而来增加该客户端对应的组播表项的老化时间。
作为一个实施例,由于该健壮系数也不可能无限增大,因此当健壮系数增加后,需要判断当前的健壮系数是否大于预设值(例如7),如果大于,则认为该客户端的组播表项的老化时间已经足够长,但是仍为收到IGMP应答报文,可以认为与该客户端的会话已经结束,因此可以删除所述客户端的组播表项。
步骤204、根据修改后的查询周期或健壮系数更新所述客户端的组播表项对应的老化时间,清空丢包计数,重新发送IGMP查询报文。
在本实施例中,无论是修改查询周期,还是修改健壮系数,都可以根据修改后的查询周期或健壮系数更新所述客户端的组播表项对应的老化时间,然后清空丢包计数,重新发送IGMP查询报文,进入下一个查询周期。
作为一个实施例,上述老化时间的计算方法具体为:
老化时间=健壮系数*查询周期+最大响应时间;
在本实施例中,最大响应时间可以根据实际网络状态设定,例如10秒等,此处不做限定。
此外,如果用户手动配置了查询周期和健壮系数,BRAS设备可以提示用户可能存在的风险并按照用户配置进行生效。此时BRAS设备可以关闭对IGMP report报文丢包统计,并关闭IGMP老化参数(查询周期和健壮系数)的自动调整机制。
相比于现有技术中按照固定的老化参数进行组播表项维护,本公开可以根据设备繁忙程度和丢包情况对老化参数进行自动调整,从而避免了大组播应用中可能出现的网络设备繁忙导致丢包和组播老化等问题,解决了用户因为丢包而收不到组播流量的问题,提升了组网的灵活性,优化了组播用户体验。
为使本公开的目的、技术方案及优点更加清楚明白,下面基于图1的组网结构,通过图3对本公开的方案作进一步地详细说明。
请参见图3,是本公开的实施例中另一种防止丢包的方法的处理流程图,其中包括:
步骤301、当到达查询周期时,获取丢包计数;转步骤302;
BRAS设备用户侧接口启用IGMP和IGMP join-by-session后,开始对BRAS设备的IGMP report报文进行丢包统计。BRAS设备获取并记录IGMP report丢包计数。
步骤302、判断丢包计数是否大于0,若是,则转步骤303;若否,则转步骤309;
步骤303、获取CPU使用率,判断CPU使用率是否大于60%,若是,则转步骤305;若否,则转步骤304;
由于BRAS设备本身可以维护CPU繁忙情况,因此BRAS设备可以直接获取CPU使用率,然后判断CPU使用率是否大于预设阈值,例如60%。若大于,则说明CPU繁忙;否则说明CPU不繁忙。
步骤304、判断查询周期+10后是否大于250秒,若是,则转步骤305;若否,则转步骤307;
查询时间周期可以设置一个初始值,每次增大值为10秒,最大周期为250秒,则每次将查询周期增加10秒后需要判断是否大于最大周期。
步骤305、判断健壮系统+1后是否大于7,若是,则转步骤306;若否,则转步骤307;
当查询周期大于最大周期或者CPU繁忙时,可以修改健壮系数,即将健壮系数+1。由于健壮系数最大值为7,因此还需要判断增大后的健壮系数是否大于7。健壮系数增加后,查询周期则会恢复初始值。
步骤306、删除组播表项;
如果健壮系数大于7,则删除该客户端对应的组播表项。
步骤307、更新老化定时器,转步骤308;
如果健壮系数不大于7,则可以根据修改后的健壮系数和查询周期更新老化定时器的时长,从而延长组播表项的老化时间。
步骤308、清空丢包计数,发送IGMP查询报文,转步骤309;
更新老化定时器后,可以清空丢包计数,并重新发送IGMP查询报文,已准备进入下一个查询周期。
步骤309、按照正常组播流程处理,然后等到达下一个查询周期时重复上述步骤301-309的操作。
因此,BRAS设备可以在按组播用户会话复制场景下,通过获取网络丢包情况和网络设备繁忙情况来自动调整组播老化时间,防止网络丢包导致组播老化。
基于相同的构思,本公开还提供一种防止丢包的装置,该装置可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,本公开的防止丢包的装置作为一个逻辑意义上的装置,是通过其所在装置的CPU将存储器中对应的计算机程序指令读取后运行而成。
请参考图4,是本公开一种示例性实施方式中的一种防止丢包的装置400,所述装置应用于BRAS设备,从逻辑层面上来看,该装置400的逻辑结构包括:
判断单元401,用于若检测到客户端针对IGMP查询报文发送的IGMP应答报文存在丢包,则判断当前CPU使用率是否小于阈值;
第一增加单元402,用于若CPU使用率小于阈值,则将所述客户端的组播表项对应的查询周期增加预设时长;
第二增加单元403,用于若CPU使用率大于等于阈值,则增加所述客户端的组播表项对应的健壮系数;
第一更新单元404,用于根据修改后的查询周期或健壮系数更新所述客户端的组播表项对应的老化时间,清空丢包计数,重新发送IGMP查询报文。
作为一个实施例,所述装置还包括:
第二更新单元405,用于当所述查询周期大于预设最大周期时,增加所述健壮系数,并将查询周期的时长恢复到初始值。
作为一个实施例,更新老化时间,包括:
老化时间=健壮系数*查询周期+最大响应时间。
作为一个实施例,所述装置还包括:
删除单元406,用于若所述健壮系数大于预设值,则删除所述客户端的组播表项。
基于相同的构思,本公开还提供一种计算机设备,如图5所示,所述计算机设备包括存储器51、处理器52、通信接口53以及通信总线54;其中,所述存储器51、处理器52、通信接口53通过所述通信总线54进行相互间的通信;
所述存储器51,用于存放计算机程序;
所述处理器52,用于执行所述存储器51上所存放的计算机程序,所述处理器52执行所述计算机程序时实现本公开实施例提供的防止丢包的方法的任一步骤。
本公开还提供一种计算机可读存储介质,所述计算机可读存储介质内存储有计算机程序,所述计算机程序被处理器执行时实现本公开实施例提供的防止丢包的方法的任一步骤。
本说明书中的各个实施例均采用相关的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于计算机设备和计算机可读存储介质的实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
综上所述,本公开可以使BRAS设备在当前查询周期内,若检测到客户端针对IGMP查询报文发送的IGMP应答报文存在丢包时,根据CPU的繁忙程度进行适当的调整,即若CPU不繁忙,则可以通过增加查询周期时长更新老化时间;若CPU繁忙,则通过增加健壮系数更新老化时间。相比于现有技术中按照固定的老化参数进行组播表项维护,本公开可以根据设备繁忙程度和丢包情况对老化参数进行自动调整,从而避免了大组播应用中可能出现的网络设备繁忙导致丢包和组播老化等问题,解决了用户因为丢包而收不到组播流量的问题,提升了组网的灵活性,优化了组播用户体验。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。
Claims (10)
1.一种防止丢包的方法,其特征在于,所述方法应用于BRAS设备,所述方法包括:
若检测到客户端针对IGMP查询报文发送的IGMP应答报文存在丢包,则判断当前CPU使用率是否小于阈值;
若是,则将所述客户端的组播表项对应的查询周期增加预设时长;
若否,则增加所述客户端的组播表项对应的健壮系数;
根据修改后的查询周期或健壮系数更新所述客户端的组播表项对应的老化时间,清空丢包计数,重新发送IGMP查询报文。
2.根据权利要求1所述的方法,其特征在于,所述方法还包括:
若所述查询周期大于预设最大周期,则增加所述客户端的组播表项对应的健壮系数,并将查询周期的时长恢复到初始值。
3.根据权利要求1或2所述的方法,其特征在于,更新老化时间,包括:
老化时间=健壮系数*查询周期+最大响应时间。
4.根据权利要求1所述的方法,其特征在于,所述方法还包括:
若所述健壮系数大于预设值,则删除所述客户端的组播表项。
5.一种防止丢包的装置,其特征在于,所述装置应用于BRAS设备,所述装置包括:
判断单元,用于若检测到客户端针对IGMP查询报文发送的IGMP应答报文存在丢包,则判断当前CPU使用率是否小于阈值;
第一增加单元,用于若CPU使用率小于阈值,则将所述客户端的组播表项对应的查询周期增加预设时长;
第二增加单元,用于若CPU使用率大于等于阈值,则增加所述客户端的组播表项对应的健壮系数;
第一更新单元,用于根据修改后的查询周期或健壮系数更新所述客户端的组播表项对应的老化时间,清空丢包计数,重新发送IGMP查询报文。
6.根据权利要求5所述的装置,其特征在于,所述装置还包括:
第二更新单元,用于若所述查询周期大于预设最大周期,则增加所述健壮系数,并将查询周期的时长恢复到初始值。
7.根据权利要求5所述的装置,其特征在于,更新老化时间,包括:
老化时间=健壮系数*查询周期+最大响应时间。
8.根据权利要求5所述的装置,其特征在于,所述装置还包括:
删除单元,用于若所述健壮系数大于预设值,则删除所述客户端的组播表项。
9.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质内存储有计算机程序,所述计算机程序被处理器执行时实现权利要求1-4任一所述方法的步骤。
10.一种计算机设备,其特征在于,所述计算机设备包括存储器、处理器、通信接口以及通信总线;其中,所述存储器、处理器、通信接口通过所述通信总线进行相互间的通信;
所述存储器,用于存放计算机程序;
所述处理器,用于执行所述存储器上所存放的计算机程序,所述处理器执行所述计算机程序时实现权利要求1-4任一所述方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811392076.8A CN109327398B (zh) | 2018-11-21 | 2018-11-21 | 一种防止丢包的方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811392076.8A CN109327398B (zh) | 2018-11-21 | 2018-11-21 | 一种防止丢包的方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109327398A true CN109327398A (zh) | 2019-02-12 |
CN109327398B CN109327398B (zh) | 2021-05-28 |
Family
ID=65258873
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811392076.8A Active CN109327398B (zh) | 2018-11-21 | 2018-11-21 | 一种防止丢包的方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109327398B (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111526092A (zh) * | 2020-03-18 | 2020-08-11 | 杭州迪普科技股份有限公司 | 组播转发表更新方法、装置、电子设备及计算机可读介质 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090161566A1 (en) * | 2007-12-13 | 2009-06-25 | Alcatel Lucent | Network Management System and Method for Performing Scalable Loss Measurements within an Access Network |
CN102064956A (zh) * | 2010-09-30 | 2011-05-18 | 中兴通讯股份有限公司 | 老化时间的调整方法及系统、调制解调器 |
CN102594686A (zh) * | 2012-02-20 | 2012-07-18 | 深圳市共进电子股份有限公司 | 一种组播终端快速离开组播的实现方法 |
CN102983984A (zh) * | 2011-09-05 | 2013-03-20 | 盛科网络(苏州)有限公司 | 解决组播表项老化的方法及系统 |
WO2014131328A1 (en) * | 2013-02-27 | 2014-09-04 | International Business Machines Corporation | Synchronizing multicast groups |
CN106603261A (zh) * | 2015-10-15 | 2017-04-26 | 华为技术有限公司 | 热备份方法、第一主用设备、备用设备和通信系统 |
CN108092841A (zh) * | 2016-11-22 | 2018-05-29 | 中兴通讯股份有限公司 | 一种网关路由信息的维护方法、装置及系统 |
CN108834081A (zh) * | 2018-05-25 | 2018-11-16 | 北京星网锐捷网络技术有限公司 | 一种组播业务处理方法及ap |
-
2018
- 2018-11-21 CN CN201811392076.8A patent/CN109327398B/zh active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090161566A1 (en) * | 2007-12-13 | 2009-06-25 | Alcatel Lucent | Network Management System and Method for Performing Scalable Loss Measurements within an Access Network |
CN102064956A (zh) * | 2010-09-30 | 2011-05-18 | 中兴通讯股份有限公司 | 老化时间的调整方法及系统、调制解调器 |
CN102983984A (zh) * | 2011-09-05 | 2013-03-20 | 盛科网络(苏州)有限公司 | 解决组播表项老化的方法及系统 |
CN102594686A (zh) * | 2012-02-20 | 2012-07-18 | 深圳市共进电子股份有限公司 | 一种组播终端快速离开组播的实现方法 |
WO2014131328A1 (en) * | 2013-02-27 | 2014-09-04 | International Business Machines Corporation | Synchronizing multicast groups |
CN106603261A (zh) * | 2015-10-15 | 2017-04-26 | 华为技术有限公司 | 热备份方法、第一主用设备、备用设备和通信系统 |
CN108092841A (zh) * | 2016-11-22 | 2018-05-29 | 中兴通讯股份有限公司 | 一种网关路由信息的维护方法、装置及系统 |
CN108834081A (zh) * | 2018-05-25 | 2018-11-16 | 北京星网锐捷网络技术有限公司 | 一种组播业务处理方法及ap |
Non-Patent Citations (1)
Title |
---|
吴建波: ""运营商IPTV组播方案及策略研究"", 《中国新通信》 * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111526092A (zh) * | 2020-03-18 | 2020-08-11 | 杭州迪普科技股份有限公司 | 组播转发表更新方法、装置、电子设备及计算机可读介质 |
Also Published As
Publication number | Publication date |
---|---|
CN109327398B (zh) | 2021-05-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108632931B (zh) | 一种基于5g网络的数据传输方法、装置、设备及介质 | |
JP2010518753A (ja) | ネットワークにおけるレイヤ2マネージメントエンティティメッセージングフレームワーク | |
CN106612196B (zh) | 获取资源的方法及装置 | |
CN112121413B (zh) | 功能服务的响应方法、系统、装置、终端及介质 | |
WO2011088767A1 (zh) | 内容分发的方法、系统及调度服务器 | |
CN104243609B (zh) | 一种信息业务推送方法和装置 | |
CN103312593B (zh) | 一种消息分发系统及方法 | |
CN108228393A (zh) | 一种可扩展的大数据高可用的实现方法 | |
EP3917084A1 (en) | Network as service service cross-domain orchestration method, orchestration device, and control device | |
CN110545327A (zh) | 一种信息推送方法及系统 | |
CN106059936A (zh) | 云系统组播文件的方法及装置 | |
CN107872492B (zh) | 一种在服务端支持多用户编辑数据对象的方法和装置 | |
CN109327398A (zh) | 一种防止丢包的方法及装置 | |
CN101542990B (zh) | 通信系统中的递送报告 | |
CN112866390B (zh) | 一种数据传输方法、装置、终端设备和存储介质 | |
WO2024066938A1 (zh) | 直播截图方法、装置、设备及存储介质 | |
CN110380981B (zh) | 一种流量分发方法及设备 | |
CN114640705B (zh) | 一种大规模物联终端心跳监控方法 | |
CN105592485A (zh) | 一种基于snmp网管协议实时采集并处理消息的方法 | |
CN109787870A (zh) | 接入管理方法、装置、系统、初始及目标接入设备 | |
WO2022148299A1 (zh) | 一种文件传输方法、装置、设备及存储介质 | |
KR102020112B1 (ko) | 데이터 분산 서비스 기반 iec61850 요청-응답 통신 방법 및 플랫폼 | |
KR20090047426A (ko) | 통신 네트워크의 실시간 데이터 전송에서 피투피 전송과 실시간 데이터 서버를 동시에 이용하여 실시간 데이터를 전송하는 방법 | |
CN110932987A (zh) | 用于流控url连接数的方法及装置 | |
CN106487916B (zh) | 一种连接数的统计方法及装置 |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
TR01 | Transfer of patent right |
Effective date of registration: 20230703 Address after: 310052 11th Floor, 466 Changhe Road, Binjiang District, Hangzhou City, Zhejiang Province Patentee after: H3C INFORMATION TECHNOLOGY Co.,Ltd. Address before: 310052 Changhe Road, Binjiang District, Hangzhou, Zhejiang Province, No. 466 Patentee before: NEW H3C TECHNOLOGIES Co.,Ltd. |
|
TR01 | Transfer of patent right |