发明内容
为了克服“背景技术”部分所反映的缺陷,在高丢包率的云系统中进行有效的文件组播,本发明提供高丢包率云系统组播文件的方法及装置。
高丢包率云系统组播文件的方法,包括:
1)控制节点通知存储服务器和所有相关的实例系统加入组播组;
2)存储服务器组播数据包并侦听实例系统的丢包反馈;
3)存储服务器组播数据包完毕后,无丢包的实例系统退出组播组,存储服务器根据侦听结果向有丢包的实例系统再次组播丢失的数据包;
4)重复3)直到有丢包的实例系统的数量小于设定的阈值;
5)存储服务器退出组播组,有丢包的实例系统从存储服务器单独获取丢失的数据包。
进一步的,1)中,通知包括存储服务器IP和第一端口号,组播IP和第二端口号,需要传输的文件的文件名、文件验证值、文件大小。
更进一步的,实例系统通过存储服务器IP和第一端口号告知存储服务器该实例系统已经加入或退出组播组。
进一步的,2)中,数据包包括数据块和文件偏移量,实例系统收到数据包后合并所有已接收的数据块,通过合并数据块在文件中的范围判断是否存在丢包。
更进一步的,如果合并数据块的块数超过第一设定值,则将合并数据块按照从小到大的顺序排序,删除排在第二设定值之前的合并数据块。
进一步的,2)或3)中,如果丢包率超过设定比率的实例系统达到设定数量,则存储服务器降低数据包的组播速度。
进一步的,3)中,侦听结果为存储服务器组播数据包完毕经过设定时限后侦听的实例系统丢包反馈。
高丢包率云系统组播文件的装置,包括存储服务器,存储服务器用于组播数据包并侦听实例系统的丢包反馈,还用于根据侦听结果向有丢包的实例系统再次组播丢失的数据包。
由于高丢包率云系统组播文件的装置,与之前所述的高丢包率云系统组播文件的方法具有明确的关联性,为了避免不必要的重复,高丢包率云系统组播文件的装置中的一些描述进行了省略。本领域技术人员通过对照,能够对高丢包率云系统组播文件的装置有清晰、完整的认识。
本发明技术方案中,“包括”、“用于”等词语应按照开放式表达方式理解。本领域技术人员通过阅读本说明书并结合现有技术或公知常识能够获知的内容,本说明书中不再赘述。
本发明提供的高丢包率云系统组播文件的方法及装置,在云系统网络设备(网卡、集线器、交换机、路由器等)的丢包率达到千分之一水平时仍能以组播方式稳定的传输文件(特别是大文件),组播过程中能够及时发现数据丢包,通过多次组播和单独传输相结合确保所有相关的实例系统都能正确接收文件。
具体实施方式
下面对本发明的实施方式进行进一步的具体说明。但应注意,本发明的范围并不局限于所描述的具体技术方案。任何对所描述的具体技术方案中的技术要素进行相同或等同替换获得的技术方案或本领域技术人员在所描述的具体技术方案的基础上不经过创造性劳动就可以获得的技术方案,都应当视为落入本发明的保护范围。
某种操作系统加上运行该操作系统所需的必要硬件(例如处理器、存储器等),可以构成一个实例系统。将若干个实例系统按照一定的架构方式集中管理,可以形成云系统。当需要向云系统中的海量实例系统传输同一个文件时,组播文件的方式不仅速度很快,而且能大大降低带宽占用。但目前组播只能通过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组播缺乏变速和重传机制的缺陷,且能够保证重传的数据量不大,不影响云系统的正常运行。
本领域技术人员在以上所描述的具体技术方案的基础上,完全可以构造出其他方案,在此不一一列举。