CN106341241A - 高丢包率云系统组播文件的方法及装置 - Google Patents

高丢包率云系统组播文件的方法及装置 Download PDF

Info

Publication number
CN106341241A
CN106341241A CN201610685385.9A CN201610685385A CN106341241A CN 106341241 A CN106341241 A CN 106341241A CN 201610685385 A CN201610685385 A CN 201610685385A CN 106341241 A CN106341241 A CN 106341241A
Authority
CN
China
Prior art keywords
multicast
storage server
packet loss
packet
file
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
CN201610685385.9A
Other languages
English (en)
Other versions
CN106341241B (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.)
Anhui Haima Cloud Technology Co ltd
Original Assignee
Beijing Haiyu Dongxiang Technology Co Ltd
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 Beijing Haiyu Dongxiang Technology Co Ltd filed Critical Beijing Haiyu Dongxiang Technology Co Ltd
Priority to CN201610685385.9A priority Critical patent/CN106341241B/zh
Publication of CN106341241A publication Critical patent/CN106341241A/zh
Application granted granted Critical
Publication of CN106341241B publication Critical patent/CN106341241B/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
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868Measures taken after transmission, e.g. acknowledgments
    • 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1809Selective-repeat protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership

Landscapes

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

Abstract

本发明提供的高丢包率云系统组播文件的方法及装置,在云系统网络设备(网卡、集线器、交换机、路由器等)的丢包率达到千分之一水平时仍能以组播方式稳定的传输文件(特别是大文件),组播过程中能够及时发现数据丢包,通过多次组播和单独传输相结合确保所有相关的实例系统都能正确接收文件。

Description

高丢包率云系统组播文件的方法及装置
技术领域
本发明涉及高丢包率云系统组播文件的方法及装置。
背景技术
某种操作系统(例如安卓操作系统)加上运行该操作系统所需的必要硬件(例如处理器、存储器等),可以视为一个实例系统,实例系统中可以运行各种应用(应用指能够在实例系统的操作系统中运行的软件或程序)。将若干个实例系统按照一定的架构方式(例如分布式)集中管理,可以形成云系统。通常云系统由运营商负责日常运营,为用户提供服务。
很多情况下,运营商需要把某个应用安装到大量的实例系统上,或者对所有实例系统的操作系统进行升级(例如该操作系统发布了重大安全补丁)。这时可以采用组播(组播是IP网络数据传输的三种方式之一,在发送者和每一接收者之间实现点对多点网络连接)的方式对相关的实例系统推送应用安装包或者操作系统升级包。相对于传统的控制节点通过TCP协议(Transmission Control Protocol,传输控制协议)多线程并行推送文件的方式,组播方式不仅速度很快,而且能大大降低带宽占用。目前组播只能通过UDP协议(UserDatagram Protocol,用户数据报协议)实现,如果网络传输质量较差,UDP协议数据包(UDP包)丢包会比较严重。由于云系统传输数据使用的是内部建立的局域网,网络传输质量很好,不容易丢包,UDP协议很适合这种场景。
但对于一些云系统,出于成本或其他方面的考虑,是通过广域网或者廉价网络设备搭建的局域网传输数据的,导致了数据传输中的高丢包率(此处的高丢包率是相对于网络传输质量很好的局域网而言的。例如目前廉价网络设备的丢包率在千分之一左右,千分之一这个数值单独看并不高,但和网络传输质量很好的局域网相比就非常高了)。这往往导致运营商的两难选择,要么因为高丢包率而放弃组播方式,要么花费数倍甚至更高的成本更换性能较好的网络设备。在高丢包率的云系统中如何有效进行文件组播,尚未见报道。
在说明书“背景技术”部分公开的内容,有助于本领域技术人员理解本发明的技术方案,但不应据此认为这些内容一定属于现有技术或公知常识。
发明内容
为了克服“背景技术”部分所反映的缺陷,在高丢包率的云系统中进行有效的文件组播,本发明提供高丢包率云系统组播文件的方法及装置。
高丢包率云系统组播文件的方法,包括:
1)控制节点通知存储服务器和所有相关的实例系统加入组播组;
2)存储服务器组播数据包并侦听实例系统的丢包反馈;
3)存储服务器组播数据包完毕后,无丢包的实例系统退出组播组,存储服务器根据侦听结果向有丢包的实例系统再次组播丢失的数据包;
4)重复3)直到有丢包的实例系统的数量小于设定的阈值;
5)存储服务器退出组播组,有丢包的实例系统从存储服务器单独获取丢失的数据包。
进一步的,1)中,通知包括存储服务器IP和第一端口号,组播IP和第二端口号,需要传输的文件的文件名、文件验证值、文件大小。
更进一步的,实例系统通过存储服务器IP和第一端口号告知存储服务器该实例系统已经加入或退出组播组。
进一步的,2)中,数据包包括数据块和文件偏移量,实例系统收到数据包后合并所有已接收的数据块,通过合并数据块在文件中的范围判断是否存在丢包。
更进一步的,如果合并数据块的块数超过第一设定值,则将合并数据块按照从小到大的顺序排序,删除排在第二设定值之前的合并数据块。
进一步的,2)或3)中,如果丢包率超过设定比率的实例系统达到设定数量,则存储服务器降低数据包的组播速度。
进一步的,3)中,侦听结果为存储服务器组播数据包完毕经过设定时限后侦听的实例系统丢包反馈。
高丢包率云系统组播文件的装置,包括存储服务器,存储服务器用于组播数据包并侦听实例系统的丢包反馈,还用于根据侦听结果向有丢包的实例系统再次组播丢失的数据包。
由于高丢包率云系统组播文件的装置,与之前所述的高丢包率云系统组播文件的方法具有明确的关联性,为了避免不必要的重复,高丢包率云系统组播文件的装置中的一些描述进行了省略。本领域技术人员通过对照,能够对高丢包率云系统组播文件的装置有清晰、完整的认识。
本发明技术方案中,“包括”、“用于”等词语应按照开放式表达方式理解。本领域技术人员通过阅读本说明书并结合现有技术或公知常识能够获知的内容,本说明书中不再赘述。
本发明提供的高丢包率云系统组播文件的方法及装置,在云系统网络设备(网卡、集线器、交换机、路由器等)的丢包率达到千分之一水平时仍能以组播方式稳定的传输文件(特别是大文件),组播过程中能够及时发现数据丢包,通过多次组播和单独传输相结合确保所有相关的实例系统都能正确接收文件。
附图说明
图1为具体实施方式中高丢包率云系统组播文件的方法的流程图。
图2为具体实施方式中云系统的控制节点、实例系统和存储服务器的关系示意图。
具体实施方式
下面对本发明的实施方式进行进一步的具体说明。但应注意,本发明的范围并不局限于所描述的具体技术方案。任何对所描述的具体技术方案中的技术要素进行相同或等同替换获得的技术方案或本领域技术人员在所描述的具体技术方案的基础上不经过创造性劳动就可以获得的技术方案,都应当视为落入本发明的保护范围。
某种操作系统加上运行该操作系统所需的必要硬件(例如处理器、存储器等),可以构成一个实例系统。将若干个实例系统按照一定的架构方式集中管理,可以形成云系统。当需要向云系统中的海量实例系统传输同一个文件时,组播文件的方式不仅速度很快,而且能大大降低带宽占用。但目前组播只能通过UDP协议实现,和TCP协议相比,UDP协议容易出现数据包丢包。如果云系统网络设备有较高的丢包率,为了保证组播方式的稳定性,避免因为丢包导致组播的文件无法使用,需要建立特殊的高丢包率云系统组播文件的方法。
高丢包率云系统组播文件的方法,如图1所示,包括如下步骤:
S101:控制节点通知存储服务器和所有相关的实例系统加入组播组。
具体的,本步骤中,当云系统的控制节点(控制节点用于控制和管理云系统中的全部或部分实例系统,作为一种实施方式,由具有X86架构的控制服务器实现)收到传输文件(特别是传输大文件)到很多个实例系统的请求时,建立一个组播组,通知存储服务器和所有相关的实例系统加入组播组。存储服务器通常是云系统中独立的高性能存储服务器,具有较高的配置(例如8核处理器、64G大内存等),存储了需要传输给很多个实例系统的文件(特别是大文件)。
控制节点通过TCP连接或者REST(Roy Thomas Fielding博士在2000年首次提出的互联网软件架构概念)协议并行通知所有相关的实例系统加入组播组,通知的内容包括存储服务器IP和第一端口号,组播IP和第二端口号,需要传输的文件的文件名、文件验证值、文件大小(也可以称为文件长度或文件总长度)等,其中文件验证值常选用MD5(消息摘要算法第五版,为广泛使用的一种散列函数,用以提供消息的完整性保护)。第一端口号用于实例系统和存储服务器之间的通信,便于存储服务器实时侦听实例系统的丢包反馈。第二端口号用于组播数据包。实例系统加入组播组后,准备接收存储服务器组播的数据包(UDP包)。
控制节点通过TCP连接通知存储服务器加入组播组,通知的内容包括第一端口号、组播IP和第二端口号、需要传输的文件的文件名等。
本发明技术方案有一个特殊的设置,实例系统通过存储服务器IP和第一端口号与存储服务器TCP连接通信,实例系统可以直接告知存储服务器该实例系统已经加入或退出组播组。通常云系统中的实例系统和存储服务器都受到控制节点的控制和管理,彼此之间通过控制节点进行通信即可。但本发明技术方案中,由于存储服务器要实时了解组播组中所有的实例系统接收数据包的情况,通过控制节点通信可能产生滞后甚至错误,存储服务器与实例系统直接通信有利于本发明技术方案的实现。
S102:存储服务器组播数据包并侦听实例系统的丢包反馈。
具体的,本步骤中,存储服务器将需要传输的文件分割为多块数据块,生成数据包(UDP包),每个数据包都包括数据块和文件偏移量(从文件指定位置向前或向后移动的字节数)。实例系统根据之前收到的控制节点的通知,在实例系统的存储器上选择合适的位置,依照文件名和文件大小创建一个新文件。每接收一个UDP包,实例系统将UDP包中的数据块直接按照文件偏移量写入创建的文件(根据文件偏移量数据块能够写入正确的位置),同时合并所有已接收的数据块,通过合并数据块在文件中的范围判断是否存在丢包。正常情况下,UDP包是按照数据块在需要传输的文件中的先后顺序依次发送的,合并数据块在文件中的范围就是从文件起始位置到当前偏移,中间没有间断。如果合并数据块在文件中的范围出现了间断,则意味着数据包可能丢包。
下面通过一个理想化的简单示例进一步展示丢包的判断过程。实例系统收到控制节点的通知显示需要传输一个名称为ust、大小5KB的文件,则实例系统在存储器上选择合适的位置,创建一个名称为ust、大小5KB的新文件。
存储服务器将需要传输的ust文件分割为5块数据块,每块数据块1KB,生成5个UDP包,每个UDP包中包括1KB的数据块和文件偏移量(从ust的起始位置计算,分别为0K、1K、2K、3K、4K)。
情形1:正常情况,存储服务器按照文件偏移量0K、1K、2K、3K、4K的顺序发送UDP包,实例系统也按照文件偏移量0K、1K、2K、3K、4K的顺序接收UDP包。
实例系统接收文件偏移量0K的UDP包,按照文件偏移量从创建的ust文件的起始位置写入数据块,合并所有已接收的数据块在创建的文件中的范围,合并的结果是创建的ust文件0K到1K的范围被写入数据;实例系统接收文件偏移量1K的UDP包,按照文件偏移量从距离创建的ust文件起始位置1K的位置写入数据块,合并所有已接收的数据块在创建的文件中的范围,合并的结果是创建的ust文件0K到2K的范围被写入数据,中间无间断。依次类推,当实例系统接收5个UDP包后,创建的ust文件0K到5K的范围都被写入数据,中间无间断,这意味着所有的UDP包都已接收,不存在丢包。
情形2:UDP包丢包,存储服务器按照文件偏移量0K、1K、2K、3K、4K的顺序发送UDP包,实例系统却只收到按照文件偏移量0K、1K、3K、4K的UDP包,文件偏移量2K的UDP包丢包。
实例系统接收文件偏移量3K的UDP包后,合并的结果发现创建的ust文件0K到4K的范围被写入数据,但中间却有2K到3K这个间断。实例系统据此判断可能存在UDP包丢包。
从以上示例可看出,如果没有丢包,合并数据块在文件中的范围是连续的,中间没有间断,可以视为“一块数据”;如果存在丢包,合并数据块在文件中的范围是不连续的,中间存在间断,可以视为“多块数据”。
尽管是“高丢包率的云系统”,但考虑到丢包率的数值本身并不是非常高,正常情况下尽管存在丢包,但丢包量有限(一个实测例,实例系统的操作系统为安卓系统,组播480M的大文件,每个实例系统的丢包量只有1K到几百K),合并数据块的块数并不会非常多。如果合并数据块的块数非常多,很可能云系统处于异常状态,此时实例系统合并所有已接收的数据块大多是无效合并,而这会消耗实例系统的大量内存,对于内存紧张的实例系统而言可能是灾难性的(因内存缺失导致程序崩溃)。为了防止出现此类问题,可以对合并数据块进行限制。如果合并数据块的块数超过第一设定值,则考虑合并数据块的大小(数据块大小也可以称为数据块长度),按照从小到大的顺序排序,删除排在第二设定值之前的合并数据块。这相当于实例系统为了释放内存而主动丢包,丢包的原则是尽可能保留较大的数据块,舍弃较小的数据块。第一设定值和第二设定值具体取多少,可以根据实例系统内存大小、需要传输的文件的大小等因素综合考虑确定。例如将第一设定值取为9,第二设定值取为6,则合并数据块的块数超过9,即合并数据块在文件中的范围存在超过8处间断时,则将合并数据块按照数据块大小从小到大(也即数据块长度从短到长)的顺序排序,将排序结果位于6之前(即第1名到第5名)的合并数据块删除。
由于实例系统可以通过存储服务器IP和第一端口号与存储服务器TCP连接通信,基于此实例系统可以将丢包情况(无论组播过程中的丢包还是实例系统主动丢包)实时反馈给存储服务器。存储服务器通过第一端口可以实时侦听实例系统的丢包反馈。如果合并数据块在文件中的范围出现了间断,实例系统将间断的位置实时反馈给存储服务器,存储服务器结合数据包中的文件偏移量很容易知道是哪些数据包丢失了。存储服务器可以据此进行实时统计,计算每个实例系统的丢包率(丢包数量/已经组播的数据包数量),如果丢包率超过设定比率的实例系统达到设定数量,则意味着数据包的组播速度过快,存储服务器相应降低数据包的组播速度。至于具体的设定比率和设定数量取多少,可以根据云系统的实际情况确定。
S103:存储服务器组播数据包完毕后,无丢包的实例系统退出组播组,存储服务器根据侦听结果向有丢包的实例系统再次组播丢失的数据包。
具体的,本步骤中,存储服务器组播数据包完毕后(相当于完成了一次组播),有的实例系统无丢包,有的实例系统则有丢包。无丢包的实例系统退出组播组,通过TCP连接告知存储服务器。对于有丢包的的实例系统,存储服务器再次组播数据包,但并不需要组播所有的数据包,只组播丢失的数据包即可。
但实例系统向存储服务器实时反馈的丢包情况不一定准确,因为组播过程中UDP包可能存在包乱序的情况,合并数据块在文件中的范围出现了间断,不一定意味着相应的UDP包丢失了,间断可能被后来接收的迟到UDP包填补上。为了获取实例系统较为准确的丢包情况,可以设置存储服务器组播数据包完毕经过设定时限后侦听实例系统的丢包反馈,以本次侦听结果作为存储服务器再次组播丢失的数据包的依据。这样设置基于如下考虑:通常实例系统会设置一个接收时限,超过接收时限还未收到UDP包就认为UDP包已经组播完毕,不会无限等待UDP包。接收时限过后,实例系统再次检查合并数据块在文件中的范围,确认是否存在间断及间断的位置,并向存储服务器反馈,这次反馈的结果显然是非常准确的。将实例系统的接收时限加上实例系统确认是否存在间断及间断的位置所用的时间,可以作为以上所述的设定时限。
再次组播的过程中,实例系统仍可将丢包情况实时反馈给存储服务器,存储服务器仍可进行实时统计,计算每个实例系统的丢包率,如果丢包率超过设定比率的实例系统达到设定数量,则存储服务器还是相应降低数据包的组播速度。相对于S102,设定比率和设定数量的具体取值可以进行调整。
S104:重复S103直到有丢包的实例系统的数量小于设定的阈值。
具体的,本步骤相当于不满足设定的条件则不断重复S103。存储服务器向有丢包的实例系统组播丢失的数据包,本次组播完成后,无丢包的实例系统退出组播组,通过TCP连接告知存储服务器。如果仍有实例系统丢包,则存储服务器根据侦听结果向有丢包的实例系统再进行一次组播,组播这些实例系统丢失的数据包。上述过程不断重复,直到存储服务器根据侦听结果发现,有丢包的实例系统的数量已经小于设定的阈值,则本步骤结束。设定的阈值具体取多少,可以根据云系统情况综合考虑确定,总的原则是小于设定阈值的实例系统与存储服务器通过TCP连接传输文件时不会对云系统的整体性能产生明显影响。
S105:存储服务器退出组播组,有丢包的实例系统从存储服务器单独获取丢失的数据包。
具体的,步骤S104之后,存储服务器便退出组播组,如果仍有实例系统存在丢包,则这些实例系统通过TCP连接单独与存储服务器通信,获取丢失的UDP包。另外注意,实例系统接收了所有的UDP包无丢包,并不意味着需要传输的文件就正确接收了,实例系统还要检查创建的文件的文件验证值(MD5)和文件大小是否与控制节点通知中需要传输的文件的验证值(MD5)和文件大小一致,两者都一致,文件才算正确接收,否则仍视为文件接收失败。文件接收失败的实例系统,也可以通过TCP连接单独与存储服务器通信,获取需要传输的文件。云系统处于正常状态时,文件验证值或文件大小验证不一致的情况应当是非常少的,如果大量的实例系统出现了文件验证值或文件大小验证不一致的情况,运营商有必要检查云系统是否存在异常,及时排除故障。
利用高丢包率云系统组播文件的装置,可以实现以上所述的高丢包率云系统组播文件的方法。高丢包率云系统组播文件的装置,包括云系统中的控制节点、实例系统和存储服务器三个部件,它们的关系如图2所示(图2中的实线双向箭头表示控制和管理关系,虚线双向箭头表示通信关系)。存储服务器与实例系统在物理上独立,都由控制节点控制和管理。存储服务器与实例系统之间可以进行通信。存储服务器比较重要的功能(简化描述),是组播数据包并侦听实例系统的丢包反馈,根据侦听结果向有丢包的实例系统再次组播丢失的数据包。上述功能可以通过编写专用程序实现。
本发明技术方案充分发挥了高性能的存储服务器支持上百万高并发小数据量的TCP连接的特点,在实例系统发现UDP包丢包时通过TCP连接反馈给存储服务器,存储服务器能够统计分析丢包情况,进一步采取降低组播速度、再次组播丢失的UDP包等措施。同时,实例系统在异常情况下可以主动丢包,确保廉价硬件(小内存、慢速处理器)的实例系统不会因实施本发明技术方案导致程序崩溃或运行过慢。本发明技术方案在网络环境存在一定丢包率的情况下仍然能够稳定无误的组播文件(特别是大文件),解决了传统的UDP组播缺乏变速和重传机制的缺陷,且能够保证重传的数据量不大,不影响云系统的正常运行。
本领域技术人员在以上所描述的具体技术方案的基础上,完全可以构造出其他方案,在此不一一列举。

Claims (8)

1.高丢包率云系统组播文件的方法,其特征在于,所述的方法包括:
1)控制节点通知存储服务器和所有相关的实例系统加入组播组;
2)存储服务器组播数据包并侦听实例系统的丢包反馈;
3)存储服务器组播数据包完毕后,无丢包的实例系统退出组播组,存储服务器根据侦听结果向有丢包的实例系统再次组播丢失的数据包;
4)重复3)直到有丢包的实例系统的数量小于设定的阈值;
5)存储服务器退出组播组,有丢包的实例系统从存储服务器单独获取丢失的数据包。
2.根据权利要求1所述的方法,其特征在于,1)中所述的通知包括存储服务器IP和第一端口号,组播IP和第二端口号,需要传输的文件的文件名、文件验证值、文件大小。
3.根据权利要求2所述的方法,其特征在于,所述的实例系统通过存储服务器IP和第一端口号告知存储服务器该实例系统已经加入或退出组播组。
4.根据权利要求1所述的方法,其特征在于,2)中所述的数据包包括数据块和文件偏移量,实例系统收到数据包后合并所有已接收的数据块,通过合并数据块在文件中的范围判断是否存在丢包。
5.根据权利要求4所述的方法,其特征在于,如果所述的合并数据块的块数超过第一设定值,则将合并数据块按照从小到大的顺序排序,删除排在第二设定值之前的合并数据块。
6.根据权利要求1所述的方法,其特征在于,2)或3)中如果丢包率超过设定比率的实例系统达到设定数量,则存储服务器降低数据包的组播速度。
7.根据权利要求1所述的方法,其特征在于,3)中所述的侦听结果为存储服务器组播数据包完毕经过设定时限后侦听的实例系统丢包反馈。
8.高丢包率云系统组播文件的装置,包括存储服务器,其特征在于,所述的存储服务器用于组播数据包并侦听实例系统的丢包反馈,还用于根据侦听结果向有丢包的实例系统再次组播丢失的数据包。
CN201610685385.9A 2016-08-18 2016-08-18 高丢包率云系统组播文件的方法及装置 Active CN106341241B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610685385.9A CN106341241B (zh) 2016-08-18 2016-08-18 高丢包率云系统组播文件的方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610685385.9A CN106341241B (zh) 2016-08-18 2016-08-18 高丢包率云系统组播文件的方法及装置

Publications (2)

Publication Number Publication Date
CN106341241A true CN106341241A (zh) 2017-01-18
CN106341241B CN106341241B (zh) 2019-08-23

Family

ID=57824767

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610685385.9A Active CN106341241B (zh) 2016-08-18 2016-08-18 高丢包率云系统组播文件的方法及装置

Country Status (1)

Country Link
CN (1) CN106341241B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108377427A (zh) * 2018-01-29 2018-08-07 明博教育科技股份有限公司 一种实时视频传输方法和系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101656756A (zh) * 2009-09-17 2010-02-24 中国科学院声学研究所 一种发送速率自适应控制的文件传输方法及其系统
WO2011106931A1 (en) * 2010-03-03 2011-09-09 Nokia Corporation Compressed hybrid automatic repeat request feedback for device to device cluster communications
CN102204182A (zh) * 2010-12-29 2011-09-28 华为技术有限公司 一种数据传输的拥塞控制方法及装置
CN102547386A (zh) * 2012-01-12 2012-07-04 华为技术有限公司 数据重传方法、系统、组播服务器及用户终端
CN103825684A (zh) * 2008-06-26 2014-05-28 汤姆逊许可公司 无线局域网络中组播数据的应答和重传的方法和装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103825684A (zh) * 2008-06-26 2014-05-28 汤姆逊许可公司 无线局域网络中组播数据的应答和重传的方法和装置
CN101656756A (zh) * 2009-09-17 2010-02-24 中国科学院声学研究所 一种发送速率自适应控制的文件传输方法及其系统
WO2011106931A1 (en) * 2010-03-03 2011-09-09 Nokia Corporation Compressed hybrid automatic repeat request feedback for device to device cluster communications
CN102204182A (zh) * 2010-12-29 2011-09-28 华为技术有限公司 一种数据传输的拥塞控制方法及装置
CN102547386A (zh) * 2012-01-12 2012-07-04 华为技术有限公司 数据重传方法、系统、组播服务器及用户终端

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108377427A (zh) * 2018-01-29 2018-08-07 明博教育科技股份有限公司 一种实时视频传输方法和系统
CN108377427B (zh) * 2018-01-29 2021-11-26 明博教育科技股份有限公司 一种实时视频传输方法和系统

Also Published As

Publication number Publication date
CN106341241B (zh) 2019-08-23

Similar Documents

Publication Publication Date Title
US11595289B2 (en) Network testing using a programmable packet engine
Guerraoui et al. Throughput optimal total order broadcast for cluster environments
KR100946108B1 (ko) 종단간 신뢰도가 있는 그룹 통신 방법 및 장치
Paul et al. Reliable multicast transport protocol (RMTP)
Kostić et al. Bullet: High bandwidth data dissemination using an overlay mesh
Vigfusson et al. Dr. multicast: Rx for data center communication scalability
WO2015184890A1 (zh) 一种丢包的测量方法及装置
CN106059936A (zh) 云系统组播文件的方法及装置
WO2006133655A1 (fr) Procede pour la transmission fiable de donnees utilisant un protocole de multidiffusion et de diffusion individuelle et hote pour la reception des donnees
Cheng et al. A coordinated data collection approach: design, evaluation, and comparison
Cinque et al. On data dissemination for large-scale complex critical infrastructures
CN103152192B (zh) 数据传输方法及网管系统
US8345576B2 (en) Methods and systems for dynamic subring definition within a multi-ring
CN106341241A (zh) 高丢包率云系统组播文件的方法及装置
Birman et al. Spinglass: secure and scalable communication tools for mission-critical computing
Qian et al. dDrops: Detecting silent packet drops on programmable data plane
CN101286862B (zh) 接入设备中组播业务主备同步和倒换的方法
Palacios et al. High-throughput multi-multicast transfers in data center networks
Weigle et al. Peer-to-peer error recovery for hybrid satellite-terrestrial networks
WO2024221448A1 (zh) 功能实现方法、装置、设备、系统及可读存储介质
Schürmann Design and evaluation of system concepts and protocols for lossless hardware-assisted streaming of real-time measurement data over IP networks
Liu et al. IBRMP: A Reliable Multicast Protocol for InfiniBand
Agarwal et al. Initial results of the CD-1 reliable multicast experiment
Xiao et al. Providing efficient, robust error recovery through randomization
Khanna et al. Failure handling in a reliable multicast protocol for improving buffer utilization and accommodating heterogeneous receivers

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
CB02 Change of applicant information

Address after: 100102 Beijing Chaoyang District City, Fu Tong East Street, No. 1 Hospital of Wangjing SOHOT3B block 41 layer

Applicant after: BEIJING HAIYUDONGXIANG TECHNOLOGY Co.,Ltd.

Address before: 100102 Beijing Chaoyang District City, Fu Tong East Street, No. 1 Hospital of Wangjing SOHOT3B block 45 layer

Applicant before: BEIJING HAIYUDONGXIANG TECHNOLOGY Co.,Ltd.

COR Change of bibliographic data
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
CP03 Change of name, title or address
CP03 Change of name, title or address

Address after: 230031 Room 672, 6/F, Building A3A4, Zhong'an Chuanggu Science Park, No. 900, Wangjiang West Road, High-tech Zone, Hefei, Anhui

Patentee after: Anhui Haima Cloud Technology Co.,Ltd.

Address before: 100102 floor 41, block B, Wangjing SOHO T3, yard 1, Futong East Street, Chaoyang District, Beijing

Patentee before: BEIJING HAIYUDONGXIANG TECHNOLOGY Co.,Ltd.