CN101626399A - 一种音乐在线播放的调度及控制方法 - Google Patents
一种音乐在线播放的调度及控制方法 Download PDFInfo
- Publication number
- CN101626399A CN101626399A CN200910063577A CN200910063577A CN101626399A CN 101626399 A CN101626399 A CN 101626399A CN 200910063577 A CN200910063577 A CN 200910063577A CN 200910063577 A CN200910063577 A CN 200910063577A CN 101626399 A CN101626399 A CN 101626399A
- Authority
- CN
- China
- Prior art keywords
- stream
- node
- data
- son
- music
- 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
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
本发明在现有的CDN-P2P混合网络基础上,提高混合分发方式下对音频媒体文件的获取效率,有效加强网络不稳定条件下内容分发系统的适应能力,从而缩短了用户启动播放的等待时间,改善用户的播放质量。并且,缓存服务器的推出策略也让缓存服务器在大负荷的条件下兼顾用户间的公平性和服务效率。
Description
技术领域
本发明涉及网络流媒体技术领域,更具体地,涉及一种音乐在线播放的调度及控制方法。
背景技术
音乐在线播放(Music Online,MOL)是一种以大规模群体用户为服务对象,以音频数据作为主要信息载体的应用层内容分发体系。从广义的角度,MOL属于流媒体内容分发系统,但是受高速发展的对等网(Peer-to-Peer,P2P)技术的影响,MOL与传统的内容分发网(Content Delivery Network,CDN)有显著的不同,这表现在两点:(1)在技术上采用P2P和CDN相结合的内容分发技术。在大规模数字内容网络分发方面,一度占主导地位的CDN和新发展起来P2P网络具有显著的互补优势:CDN网络可降低数据传输延迟,提高用户体验;P2P网络的部署成本低,可扩展性强。MOL融合这两种技术,旨在为用户提供良好的体验质量(Quality of Experience,QoE),并将部署开销控制在合理水平;(2)在运营模式上,运营商将深度参与MOL。在传统的CDN运营模式下,CDN和电信运营商通常是分离的,即CDN通常是运营商的客户,而内容提供商是CDN的客户。MOL系统采用扁平化结构,即它由运营商主导部署,由内容提供商与运营商结成伙伴关系,向目标客户提供定制的音乐服务。因此MOL中CDN成为一个纯技术概念而不是商业实体,MOL在用户信息、网络拓扑、拥塞状况等方面将能够从运营商那里获取更丰富的信息,一方面可以帮助优化客户软件的调度算法,另一方面可以优化运营商的网络部署和规划策略。
在流媒体内容分发领域,为了提高分发和网络资源的利用效率,总体上CDN和P2P的融合是一种趋势,但是对于具体的实施方案,尚没有统一的标准,不同的厂商都采用了自己的架构。在MOL中,CDN的部署在物理上是通过一组缓存服务器(Caching Server,CS)来完成的。这些缓存服务器被运营商有策略地部署在不同地理位置的网络数据中心(Internet Data Center,IDC),具有高速的数据处理能力、大容量的存储系统和稳定高速的接入带宽,它们构成整个MOL网络服务体系的支撑点。MOL的单个用户使用配套的客户端软件,这个软件使用主流的P2P技术,即不同的用户所用普通节点(Peer)之间采用节点间协作式(Peer-assisted)的信息获取方式。与传统的CDN实现方案不同,MOL的Peer向CS获取文件时并不获取文件的全部,而是将CS视作普通节点并向其申请规定的数据。CS区别于普通节点的地方在于两点,一是CS具有较强的物理性能、上载带宽和稳定的在线服务时间;二是CS的数据直接通过专用连接从媒体源服务器获得,CS不会向普通节点获取数据。
为了在分布式环境下完成对流媒体内容的传输,需要将一个较大的音频文件划分为若干个较小的等长文件分片,目前主流的P2P技术中主要采用两种方式,一种是基于分片和缓存映射(Buffer Map)来请求信息,即每个Peer向其他Peer获取媒体文件时以分片为粒度,使用对应的位图(称为缓存位图)来表示所需要的数据分片;另一种是基于子流的方式,即按照一定的规则将文件分片组织成序列(称为子流),媒体文件的完整内容由若干个这样的子流构成,每个Peer向其他Peer申请媒体文件时以这种分片序列(也成为流)为粒度。基于分片的方式中,现有的系统可选地使用TCP或UDP作为传输层协议,而基于流的方式一般采用TCP作为传输层协议。
在传统的P2P或CDN媒体分发技术中,有被称为“推”和“拉”的两种数据分发模式。“拉”指的是数据的需求方主动向相关对等节点请求数据,而“推”指的是数据的拥有方选择合适的对等节点将自己的数据主动送出去。一般而言,在P2P网络中使用拉模式的居多,但是如果使用基于子流的方式,采用推、拉结合的方式也是一种常用手段,即先采用拉的模式请求数据,一旦数据开始传输,发送方就不停止“推送”数据,直到接收方显式地通知停止。
参见附图1,现有MOL系统主要由音频源服务器(Audio Source Server,ASS)、缓存服务器(CS)、资源服务器(Resource Manager/Designated RM,RM/DR)、普通节点(Peer)组成。ASS负责原始流媒体文件的存储和首次分发,它实时储存有不同节目的音频流,因此任何其它节点的当前播放位置都不能超过ASS可以最新提供的媒体文件片段,ASS可以根据自己的存储容量来保留最新播放位置之前、有限时间区间内的媒体文件,但新产生的媒体文件会不断替换过时的数据。资源服务器负责直播频道和相应参与Peer信息的维护,它分为主资源管理器(RM)和次级的指派资源管理器(DR)。例如图1中的系统内原有五个普通节点peer1、peer2、peer3、peer4和peer5,每个新加入节点时首先联系RM,若RM判断该Peer属于某个管理域时,就指定一个负责该域的DR,并让新加入的Peer通过此DR进一步获取邻居信息。根据MOL服务部署的规模和范围,缓存服务器CS既可以是逻辑上的服务器(如依附于ASS),也可以是一组专门用于向Peer群体提供流量帮助的服务器。在ADSL用户群体较大的网络,由于每个Peer的上传带宽不足,部署缓存服务器会对提高用户的QoE将起到重要作用。Peer为对等用户节点,也简称为普通节点。它既从自己知道的邻居那里获取媒体文件,也可以向其它节点提供自己存储的媒体文件片段。MOL系统采用了“数据驱动”的方案,即各个Peer之间不维护某种预先定义好的拓扑。
现有技术的不足之处在于(1)对网络流量场景动态变化的适应性较欠缺;(2)被部署的缓存服务器在受理普通节点请求时难以实现效率和公平性的折衷;(3)普通节点加入网络时选择父节点和定位子流的过程较长。
发明内容
为了解决现有音乐在线播放技术问题,本发明提出一种音乐在线播放的调度及控制方法。
本发明提供的技术方案为,一种音乐在线播放的调度及服务控制方法,所述音乐在线播放由音乐在线播放系统实现,所述音乐在线播放系统包括音频源服务器、缓存服务器、资源服务器和普通节点,音乐在线播放系统中的音乐媒体文件被进行文件分片和子流划分,进行文件分片时将音乐媒体文件划分为等长字节的数据分片,每个数据分片顺序编号,并通过用与数据分片相应的缓存位图来指代作为数据请求方的普通节点所需要的文件分片;其特征是:采用基于子流和基于分片的混合调度策略,具体实现方式如下,
(1)每个普通节点在进入音乐在线播放系统之后,由资源服务器获取其唯一的标识号peer ID和初始的邻居列表,普通节点根据初始的邻居列表得到可用邻居节点;然后,根据可用邻居节点返回的该节点中当前所有子流的数据状态SSD,从可用邻居节点中选择若干父节点或者选择缓存服务器为普通节点提供各个子流,
每个可用邻居节点返回的SSD都以子流为粒度,对于每个子流,可用邻居节点返回的消息的主要内容具有如下形式:
<Str(i),MaxChunk(i)> 0≤i<M
其中MaxChunk(i)表示此可用邻居节点的子流Str(i)的最大分片通告;收到来自各个可用邻居节点的SSD后,该普通节点设定一个宽度为MaxLag的子流同步滑动窗口,让划分的M支子流处于平行的位置,并让这个窗口沿这M支子流滑动,当滑动到某个位置,使得这个位置内各个可用邻居节点通告的所有子流的MaxChunk(i)具有最大数目时,则该普通节点根据该位置向相关的可用邻居节点发送子流请求,具体方法是:如果某个子流在子流同步滑动窗口内有一个或多个可用邻居节点的最大分片通告,则随机选择其中一个可用邻居节点,向它预定此子流,预定的起始处为子流同步滑动窗口的左侧位置;如果某个子流在子流同步滑动窗口内没有任何可用邻居节点的最大分片通告,则该子流随机选择一个缓存服务器预定此子流,预定的起始值同样为子流同步滑动窗口的左侧位置;收到子流的最大分片通告,但是没有被选定向其预定子流的那些可用邻居节点,成为这个普通节点的候选父节点;
(2)每个普通节点在选定了父节点或缓存服务器后,采用基于子流的方式向对方预定一个或多个数据子流,此种方式采用“推”和“拉”相结合的模式,即普通节点向父节点预定了数据子流以后,除非取消预定,否则对方将一直推送指定的数据流到作为原始数据请求方的普通节点;
(3)每个普通节点实时评估运行期间当前的网络状况,如果预定的子流由于网络状况导致当前播放点后、预设的数据分片长度门限DT以内出现数据分片空缺,则节点就采用基于分片的方式向缓存服务器和具有最大剩余带宽的候选父节点发送数据请求,请求的数据为当前播放点后、预设的数据分片长度门限DT以内且尚未到达的数据分片。
而且,每个普通节点定时检查运行期间各个子流的通信状况,具体实现方式如下,
设定一个整数门限值WarnUpperThreshold和一个系数α,α>1;定时检查距离当前播放指针以后、α·DT个槽位内的空缺数据分片;对于每一个上述范围内的空缺数据分片,将这个空缺数据分片所在的子流进行一次警告计数,一个子流有多少个空缺数据分片位于上述范围,就对这个子流警告多少次;
当有子流的受警告次数超过整数门限值WarnUpperThreshold,就尝试从其他剩余带宽更大的父节点或者候选父节点或者缓存服务器预定这个子流。而且,设置缓存服务器对请求队列的门限机制和推出机制,具体实现方式如下,
记缓存服务器最大允许的TCP连接数为MaxConnect;
缓存服务器维护一张连接状态表,用于记录每个音乐媒体文件与所承担子流的TCP连接之间的关系,它的主要表项的形式是:
<TCP Socket ID,频道号,Peer ID,连接建立时间,连接中的子流个数>
其中,TCP Socket ID是指TCP连接的套接字ID,频道号是指套接字对应的下载媒体频道,Peer ID为普通节点的标识号;
缓存服务器设置一个门限值σ,0<σ<1;当有新的普通节点向其发送子流预定请求,而现有TCP连接数超过σ·MaxConnect时,将首选具有最多TCP连接的音乐媒体文件,继而从它的TCP连接中选出持续时间最长的连接,然后在这个连接中随机选择一个子流发送清退通知,并缺省继续为该子流继续提供预设时长的数据量。
本发明在现有的CDN-P2P混合网络基础上,提高混合分发方式下对音频媒体文件的获取效率,有效加强网络不稳定条件下内容分发系统的适应能力,从而缩短了用户启动播放的等待时间,改善用户的播放质量。并且,缓存服务器的推出策略也让缓存服务器在大负荷的条件下兼顾用户间的公平性和服务效率。
附图说明
图1为现有音乐在线播放系统的总体结构示意图;
图2为本发明实施例的普通节点(Peer)的缓存结构示意图;
图3为本发明实施例的子流同步滑动窗口示意图;
图4为本发明实施例的子流通信状况的检查示意图;
图5为本发明实施例的的缓存服务器推出机制处理流程。
具体实施方式
以下结合附图和实施例对本发明进行详细的描述。
本发明在现有MOL直播系统基础上实现,主要由音频源服务器(VideoSource Server,ASS)、缓存服务器(Caching Server,CS)、资源服务器(ResourceManager/Designated RM,RM/DR)、普通节点(Peer)组成,这些部份可以通过网络连接建立信息交互,一般采用Internet即可。普通节点一般是普通音乐欣赏用户的个人主机,通过接入Internet可以方便地实现加入MOL直播系统。ASS负责原始流媒体文件的存储和首次分发,它实时储存有各个频道的音频流,并可以根据自己的存储容量来保留最新播放位置之前、有限时间区间内的媒体文件,但新产生的媒体文件会不断替换过时的数据。ASS是整个MOL系统中信息流的源,音乐媒体文件的分片、编号、子流划分规则都在ASS上确定,且确定以后在整个MOL网络中都遵循这个规则。资源服务器负责直播频道和相应参与Peer信息的维护,它分为主资源管理器(RM)和次级的指派资源管理器(DR),每个Peer加入时首先联系RM,若RM判断该Peer属于某个管理域时,就指定一个负责该域的DR,并让新加入的Peer通过此DR进一步获取邻居信息。RM为整个MOL的入口,每个新加入的普通节点都是通过RM,或由RM指派的DR,来获取最初的基本信息的。这些基本信息包括:被分配的标识号(peer ID),初始的邻居列表和CS的地址等。Peer为对等用户节点,也称为普通节点,它既从自己知道的邻居那里获取媒体文件,也可以向其它节点提供自己存储的媒体文件片段。CS是MOL的运营商有策略地部署的媒体文件缓存服务器,它们通过高速的专用链路从ASS处获取新的流媒体文件,并且为众多的普通节点提供子流。和ASS一样,CS通常都是高性能的服务器,它们一般被不属于因特网数据中心(IDC),具有较大的上传带宽和稳定的服务时间。部署CS是MOL运营商有效提高用户体验质量、吸引更多用户使用的一种常用手段。从每个普通节点的视角出发,在调度方式上CS和其他普通节点并没有显著不同,但CS可以视为一种超级节点,当联系其他普通节点发生苦难时,诉诸于向CS请求数据是一种最方便的策略。
音乐在线播放系统中,传输和运行的音乐媒体文件都被切分为等长字节的数据分片,每个数据分片顺序编号,用Ch(s)表示编号为s的分片。然后,音乐媒体文件被分为子流共M支,子流i(0≤i<M)定义为:Str(i)={Ch(s)|s=i mod(M)}。分片和分子流都是现有技术,实施例采用双滑动窗口的机制来组织来至不同子流的数据分片:一个滑动窗口与播放指针绑定,称为缓存窗口,其宽度记为LCW;另一个滑动窗口用于数据分片的请求和收取,称为请求窗口,其长度为W。若左侧的数据分片为Ch(n),则请求窗口右侧的数据分片为Ch(n+W-1)。播放指针指向普通节点当前本地的媒体播放程序正在读取的数据分片,如图2所示,其中空白的槽位表示该数据分片还没到达,有阴影的表示已到达,而标记为N的槽位表示在播放之前尚未到达的数据分片。
请求窗口表示普通节点自身期望从其各个父节点那里获取的数据分片范围,其最左侧为当前播放指针之后首个空白的槽位(因此滑动窗口的最左端槽位总是空白的),一旦左端槽位的数据分片到达,则请求窗口朝数据分片增加的方向(右)移动,直到再次出现空白槽位,并将这个新的空白槽位作为滑动窗口的左端。显然,当前播放指针到当前滑动窗口左侧之间的槽位都是连续充满的。普通节点自身会周期性向其邻居通告自身已获得的当前所有子流的数据状态SSD(Sub Stream Description),其缓存窗口将随着播放指针向后滑动,缓存窗口以外(早于缓存窗口)的历史数据分片将被丢弃。
一个节点周期性地(周期长度记为TSSD)向已知的邻居,或者当收到来自某个邻居的SSD请求后,发出自己的SSD。实施例中,SSD消息的内容格式为:
<Str(i),MaxChunk(i)> 0≤i<M
该SSD消息表示普通节点自己当前掌握了属于子流i、紧跟MaxChunk(i)以前、分片个数不少于个的数据分片。其中0≤i<M,LCW表示缓存窗口的大小。在此通告过程中,SSD消息并不携带子流i的起点。MaxChunk(i)表示此节点的子流Str(i)的最大分片通告,也就是子流Str(i)的当前最新数据分片号。
如果请求窗口的左侧距离播放指针已经较近(注意请求窗口内的左侧槽位总是没有填满的),意味着迅速得到这些空白槽位的需求已经比较紧急,这时MOL将采用基于分片请求方式来额外向可能提供这些缺损数据分片的父节点那里发送请求。因此需要一个阈值来说明发送紧急请求的触发时机。为此,定义DT(Deadline Threshold)为当前播放指针距离请求窗口左侧的最小槽位数。
当播放指针与请求窗口左侧的距离SL(sufficiency length)小于DT时,普通节点将使用以下格式向随机选择的候选父节点和随机选择的CS同时发送紧急数据分片请求:
<起始数据分片编号,缓存位图>
文件分片的起始标号和缓存位图可以指定其后的数据分片,缓存位图中比特“1”表示需要的单个数据分片,比特“0”表示相应的数据分片不在请求之列。
发送这个数据的另一种用途是测试对方节点(CS、候选父节点)和自己之间的剩余吞吐率,这在评价CS或候选父节点的质量时会起到重要作用,尽管可能会造成接收数据的冗余,在获得了数据之后,将记录已测试CS、候选父节点的当前剩余吞吐率,并更新相关数据结构的字段。
从一个Peer的角度出发,其他的节点可以分为三类,即可用邻居节点、候选父节点和父节点,可用邻居节点指Peer通过和其他节点邻居信息交换而得到的在线节点,且它们可以对此Peer的消息做出响应;候选父节点指Peer通过验证可以从其下载数据但尚未实际下载数据的那些节点;父节点指Peer正在从其下载数据的那些节点。就每个Peer而言,CS永远都是它的候选父节点或者父节点,具体处于何角色取决于Peer当前的运行状态。
初始时,每个Peer从RM/DR服务器那里获取了个数为N0的邻居列表,节点随即验证这些邻居是否可用。在运行期,每个peer在交换得到了邻居信息后,也需要验证邻居是否为可用的邻居,通过发送SSD请求消息并检查对方是否能返回相应来判断对方是否为可用邻居节点。
为了能在运行期能保持充足的数据源获取渠道,每个Peer一直在循环执行六个任务,具体实施时可以设置每个任务由一个功能模块负责实现,它们是:
●任务1:和已知的邻居交换邻居信息,从而获知更多的邻居。
●任务2:测试/选取可用邻居节点(即验证邻居是否为可用的邻居,通过发送SSD请求消息并检查对方是否能返回相应来判断对方是否为可用邻居节点),扩充自己的可用邻居节点集合。
●任务3:考察可用邻居节点的剩余带宽,判断是否可以做父节点。
●任务4:考察当前收取的数据分片同步状况,调整父节点集合以及子流在其间的分配方案。
●任务5:衡量当前通信质量,判断是否触发紧急数据分片获取行为。
●任务6:根据流量状况调整对CS的依赖性。
每个Peer在进入音乐在线播放系统之后,都会根据可用邻居节点返回的SSD首次选择一部分父节点来提供各个子流。由于每个普通Peer返回的SSD都以子流为粒度,因此收到来自各个可用邻居节点的SSD可以用如图3的子流同步滑动窗口来表示。其中水平线上的“X”符号表示收到的可用邻居节点的SSD通告中相应子流的最大分片,代表MaxChunk(i)的出现。设定一个宽度为MaxLag的子流同步滑动窗口,并让这个窗口沿横轴(数据分片序号)滑动。这样,常数MaxLag表示缓存中各个子流的最大异步容忍值,即各个子流最后序列号数据分片之间的最大差距值。当滑动到某一个位置中具有最多的“X”,这个位置即为理想的位置。对于每一个Str(i)(0≤i<M),即图中Str(0)、Str(1)…Str(M-1),在这个滑动窗口中与Str(i)相对应的行中随机地选取一个“X”,则这个“X”即为所代表的父节点:向它所代表的邻居发送对子流Str(i)的预定,预定的起始值即为滑动窗口的左侧位置。如果出现某个子流在滑动窗口内没有“X”,则该子流向随机选择的CS预定,预定的起始值同样为滑动动窗口的左侧位置。在运行期间,子流同步滑动窗口的滑动规则为:仅当所有的子流都从相应的父节点或者CS处开始接收数据时才滑动,且子流同步滑动窗口的左侧与各个子流中已经获得的最新数据分片的编号最小的子流对齐。
每个普通节点在选定了父节点或CS后,采用基于子流的方式向对方预定一个或多个数据子流,此种方式采用“推”和“拉”相结合的模式,即普通节点向父节点预定了数据子流以后,除非取消预定,否则对方将一直推送指定的数据流到作为原始数据请求方的普通节点。该部份实现参考现有技术即可,本发明不予赘述。
在选定了父节点或CS后,采用基于子流的方式传输的同时,每个普通节点实时评估运行期间当前的网络状况。如果评估网络状况的结果是,预定的子流由于网络通信质量不理想而即将出现无法满足播放进度要求的情形,则节点就采用基于分片的方式向CS和具有最大剩余带宽的候选父节点发送数据请求,请求的数据为当前播放点后、预设的数据分片长度门限DT以内且尚未到达的数据分片。即实施例的任务5。
为了能够在网络状态没有恶劣到需要更换成基于分片的方式时,自动调整优化基于子流的传输,进一步提供传输效率,本发明提供了进一步技术方案:每个普通节点定时检查运行期间各个子流的通信状况,具体实现方式如下,
设定一个整数门限值WarnUpperThreshold和一个系数α,α>1;定时检查(建议为1秒钟1次)距离当前播放指针以后、α·DT个槽位内的空缺数据分片;对于每一个上述范围内的空缺数据分片,将这个空缺数据分片所在的子流进行一次警告计数,一个子流有多少个空缺数据分片位于上述范围,就对这个子流警告多少次;
当有子流的受警告次数超过整数门限值WarnUpperThreshold,就尝试从其他剩余带宽更大的父节点或者候选父节点或者CS预定这个子流。
该方案即实现实施例的任务4。实施例在每个普通节点内部维护了一张如下所示的表:
表1子流状况实时跟踪记录
Seq(i)表示该子流的最近的数据分片序列,而Parent(i)表示该子流是由哪个父节点或者CS来提供。任何一个数据分片属于唯一的子流号,因此从数据分片的缺失可以衡量一个子流的状况。普通节点设置三个阈值,其中α(α>1)为“危险系数”,另两个分别记为WarnUpperThreshold,WarnLowerThreshold,用于评价子流受警告次数的预警级别。考虑当前的播放指针,距离该指针以后α·DT个槽位内的空缺数据分片都是“危险的”,因为它们如果在短时期内如果不能补齐,将影响到媒体的顺利播放。为此把这些距离播放指针不超过α·DT的空槽位所在的子流进行一次警告,这种检测每秒钟进行一次。如图4所示,某时刻空缺槽位n和n+1位于播放指针的α·DT范围内,那么槽位n和槽位n+1所在的子流将要受到警告,即相应的RecentWarned(i)设置为播放指针之后α·DT范围内子流i的空缺槽位数。当请求窗口的左侧距离播放指针小于DT时,将会使用紧急数据分片请求机制,但是通过紧急数据分片请求机制得到的数据分片不用于子流警告的统计。譬如说,如果数据分片n-1是通过紧急数据分片获取方式得到的,且正常的流获取方式在进行统计时还未到,那么数据分片n-1所在的子流也应该被警告。若某个子流在30秒内获得的警告超过门限值WarnUpperThreshold,则表明该子流的获取已经非常困难,需要尽可能转入其它父节点或者候选父节点或者CS;如果若该子流在30秒内获得的警告不超过门限值WarnLowerThreshold,则表示此子流的运行状况令人满意,在未找到非常胜任的新的父节点之前,可以不必更换父节点。
CS用于为普通用户在尚未找到合适父节点时,或者在获取紧急数据时提供支持。CS对普通节点的支持服务有两种模式,基于分片的和基于子流的,其中基于分片方式用于提供紧急数据,采用UDP协议,对普通节点的请求采取即来即服务的策略;基于子流方式用于向普通节点的子流预定提供一支或多支子流,采用TCP协议,用于每个CS要服务大量的潜在用户,因此每个普通节点一般只和一个CS建立一条供子流传输的TCP链接,多个子流的传输在同一个连接中复用。由于缓存服务器的TCP链接资源有限,需要将有限的连接资源进行合理分配。
对于每个频道的连接数限制,有两个方面的考虑:如果是热门频道,则用户的数量较大,因此从CS获取数据申请的数量会偏大;而如果是冷门频道,用户的数量较少,因此用户获取资源的难度也会相应提高,因此CS同样应该为冷门频道预留较多的连接数。综合两方面的因素,CS采用公平的“推出”策略来处理连接请求过载的问题,即将当前具有最多连接数的频道中,选取一个连接进行“清退操作”。
表2缓存服务器的TCP连接表
实施例中,CS维护了如上所示的表,用于记录每个TCP连接的状况。通常一个高性能服务器都会支持10K-30K个TCP连接(最大允许连接数为MaxConnect),每个TCP连接可以用TCP套接字惟一标识Sock,因此表2中每个表项可以用Sock来索引。Ch表示套接字对应的下载媒体频道,Peer表示用于请求频道的普通节点,StartTime用于记录连接建立完成的时间,StreamNum表示此连接中用来传输的子流数目。
CS的调度采用门限和推出机制:CS设置一个门限值σ(0<σ<1),“推出”机制是指当有新的节点向其发送子流预定请求,而现有TCP连接数超过σ·MaxConnect时,将首选具有最多TCP链接的媒体文件,继而从它的TCP连接中选出持续时间最长的连接,然后在这个连接中随机选择一个子流发送清退通知,也可以设置缺省继续为该子流提供预设时长(例如60秒)的数据量后清退。实施例具体的处理流程如图5所示:收到新的节点子流预定请求,且当前连接数达到σ·MaxConnect时,按照每个频道的当前连接数排序,记具有最大连接数的频道为Chmax;选择Chmax中建立时间最长的连接,查看此连接是否只有一个子流传输?如果不是,随机选择其中一个子流发送清退消息;如果是,向此子流发送清退消息。
显然,本领域的技术人员可以对本发明进行各种修改和变型而不脱离本发明的思想和范围。这样,倘若本发明的这些修改和变形属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。
Claims (3)
1.一种音乐在线播放的调度及控制方法,所述音乐在线播放由音乐在线播放系统实现,所述音乐在线播放系统包括音频源服务器、缓存服务器、资源服务器和普通节点,音乐在线播放系统中的音乐媒体文件被进行文件分片和子流划分,进行文件分片时将音乐媒体文件划分为等长字节的数据分片,每个数据分片顺序编号,并通过用与数据分片相应的缓存位图来指代作为数据请求方的普通节点所需要的文件分片;其特征是:采用基于子流和基于分片的混合调度策略,具体实现方式如下,
(1)每个普通节点在进入音乐在线播放系统之后,由资源服务器获取其唯一的标识号peer ID和初始的邻居列表,普通节点根据初始的邻居列表得到可用邻居节点;然后,根据可用邻居节点返回的该节点中当前所有子流的数据状态SSD,从可用邻居节点中选择若干父节点或者选择缓存服务器为普通节点提供各个子流,
每个可用邻居节点返回的SSD都以子流为粒度,对于每个子流,可用邻居节点返回的消息的主要内容具有如下形式:
<Str(i),MaxChunk(i)> 0≤i<M
其中MaxChunk(i)表示此可用邻居节点的子流Str(i)的最大分片通告;收到来自各个可用邻居节点的SSD后,该普通节点设定一个宽度为MaxLag的子流同步滑动窗口,让划分的M支子流处于平行的位置,并让这个窗口沿这M支子流滑动,当滑动到某个位置,使得这个位置内各个可用邻居节点通告的所有子流的MaxChunk(i)具有最大数目时,则该普通节点根据该位置向相关的可用邻居节点发送子流请求,具体方法是:如果某个子流在子流同步滑动窗口内有一个或多个可用邻居节点的最大分片通告,则随机选择其中一个可用邻居节点,向它预定此子流,预定的起始处为子流同步滑动窗口的左侧位置;如果某个子流在子流同步滑动窗口内没有任何可用邻居节点的最大分片通告,则该子流随机选择一个缓存服务器预定此子流,预定的起始值同样为子流同步滑动窗口的左侧位置;收到子流的最大分片通告,但是没有被选定向其预定子流的那些可用邻居节点,成为这个普通节点的候选父节点;
(2)每个普通节点在选定了父节点或缓存服务器后,采用基于子流的方式向对方预定一个或多个数据子流,此种方式采用“推”和“拉”相结合的模式,即普通节点向父节点预定了数据子流以后,除非取消预定,否则对方将一直推送指定的数据流到作为原始数据请求方的普通节点;
(3)每个普通节点实时评估运行期间当前的网络状况,如果预定的子流由于网络状况导致当前播放点后、预设的数据分片长度门限DT以内出现数据分片空缺,则节点就采用基于分片的方式向缓存服务器和具有最大剩余带宽的候选父节点发送数据请求,请求的数据为当前播放点后、预设的数据分片长度门限DT以内且尚未到达的数据分片。
2.如权利要求1所述音乐在线播放的调度及控制方法,其特征是:每个普通节点定时检查运行期间各个子流的通信状况,具体实现方式如下,
设定一个整数门限值WarnUpperThreshold和一个系数α,α>1;定时检查距离当前播放指针以后、α·DT个槽位内的空缺数据分片;对于每一个上述范围内的空缺数据分片,将这个空缺数据分片所在的子流进行一次警告计数,一个子流有多少个空缺数据分片位于上述范围,就对这个子流警告多少次;
当有子流的受警告次数超过整数门限值WarnUpperThreshold,就尝试从其他剩余带宽更大的父节点或者候选父节点或者缓存服务器预定这个子流。
3.如权利要求1或2所述音乐在线播放的调度及控制方法,其特征是:设置缓存服务器对请求队列的门限机制和推出机制,具体实现方式如下,
记缓存服务器最大允许的TCP连接数为MaxConnect;
缓存服务器维护一张连接状态表,用于记录每个音乐媒体文件与所承担子流的TCP连接之间的关系,它的主要表项的形式是:
<TCP Socket ID,频道号,Peer ID,连接建立时间,连接中的子流个数>
其中,TCP Socket ID是指TCP连接的套接字ID,频道号是指套接字对应的下载媒体频道,Peer ID为普通节点的标识号;
缓存服务器设置一个门限值σ,0<σ<1;当有新的普通节点向其发送子流预定请求,而现有TCP连接数超过σ·MaxConnect时,将首选具有最多TCP连接的音乐媒体文件,继而从它的TCP连接中选出持续时间最长的连接,然后在这个连接中随机选择一个子流发送清退通知,并缺省继续为该子流提供预设时长的数据量。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009100635776A CN101626399B (zh) | 2009-08-11 | 2009-08-11 | 一种音乐在线播放的调度及控制方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009100635776A CN101626399B (zh) | 2009-08-11 | 2009-08-11 | 一种音乐在线播放的调度及控制方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101626399A true CN101626399A (zh) | 2010-01-13 |
CN101626399B CN101626399B (zh) | 2012-03-28 |
Family
ID=41522080
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2009100635776A Expired - Fee Related CN101626399B (zh) | 2009-08-11 | 2009-08-11 | 一种音乐在线播放的调度及控制方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101626399B (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2011150644A1 (zh) * | 2010-12-17 | 2011-12-08 | 华为技术有限公司 | 一种启动阶段的流媒体数据获取、发送方法及装置 |
CN102387164A (zh) * | 2010-08-30 | 2012-03-21 | 上海悠络客电子科技有限公司 | 一种p2p网络数据传输的方法 |
CN103188279A (zh) * | 2011-12-27 | 2013-07-03 | 中国电信股份有限公司 | 通过对等网络从多个邻居节点下载文件的方法和装置 |
CN103731398A (zh) * | 2012-10-11 | 2014-04-16 | 北京百度网讯科技有限公司 | 基于cdn网络的数据访问方法、系统及装置 |
CN103794240A (zh) * | 2012-11-02 | 2014-05-14 | 腾讯科技(深圳)有限公司 | 在线音频数据的存储方法及装置 |
CN106210803A (zh) * | 2016-07-12 | 2016-12-07 | 乐视控股(北京)有限公司 | 一种媒体节目的播放方法及装置 |
CN106453122A (zh) * | 2016-09-23 | 2017-02-22 | 北京奇虎科技有限公司 | 一种流数据传输节点的选取方法和装置 |
CN109104451A (zh) * | 2017-06-21 | 2018-12-28 | 阿里巴巴集团控股有限公司 | Docker镜像的下载方法及节点、Docker镜像的预热方法及节点 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100461740C (zh) * | 2007-06-05 | 2009-02-11 | 华为技术有限公司 | 一种客户端节点网络拓扑构造方法及流媒体分发系统 |
-
2009
- 2009-08-11 CN CN2009100635776A patent/CN101626399B/zh not_active Expired - Fee Related
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102387164A (zh) * | 2010-08-30 | 2012-03-21 | 上海悠络客电子科技有限公司 | 一种p2p网络数据传输的方法 |
CN102387164B (zh) * | 2010-08-30 | 2014-05-14 | 上海悠络客电子科技有限公司 | 一种p2p网络数据传输的方法 |
WO2011150644A1 (zh) * | 2010-12-17 | 2011-12-08 | 华为技术有限公司 | 一种启动阶段的流媒体数据获取、发送方法及装置 |
CN103188279A (zh) * | 2011-12-27 | 2013-07-03 | 中国电信股份有限公司 | 通过对等网络从多个邻居节点下载文件的方法和装置 |
CN103188279B (zh) * | 2011-12-27 | 2016-06-01 | 中国电信股份有限公司 | 通过对等网络从多个邻居节点下载文件的方法和装置 |
CN103731398A (zh) * | 2012-10-11 | 2014-04-16 | 北京百度网讯科技有限公司 | 基于cdn网络的数据访问方法、系统及装置 |
CN103794240A (zh) * | 2012-11-02 | 2014-05-14 | 腾讯科技(深圳)有限公司 | 在线音频数据的存储方法及装置 |
CN103794240B (zh) * | 2012-11-02 | 2017-07-14 | 腾讯科技(深圳)有限公司 | 在线音频数据的存储方法及装置 |
CN106210803A (zh) * | 2016-07-12 | 2016-12-07 | 乐视控股(北京)有限公司 | 一种媒体节目的播放方法及装置 |
CN106453122A (zh) * | 2016-09-23 | 2017-02-22 | 北京奇虎科技有限公司 | 一种流数据传输节点的选取方法和装置 |
CN106453122B (zh) * | 2016-09-23 | 2019-06-04 | 北京奇虎科技有限公司 | 一种流数据传输节点的选取方法和装置 |
CN109104451A (zh) * | 2017-06-21 | 2018-12-28 | 阿里巴巴集团控股有限公司 | Docker镜像的下载方法及节点、Docker镜像的预热方法及节点 |
Also Published As
Publication number | Publication date |
---|---|
CN101626399B (zh) | 2012-03-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101626399B (zh) | 一种音乐在线播放的调度及控制方法 | |
Wang et al. | Offloading mobile data traffic for QoS-aware service provision in vehicular cyber-physical systems | |
CN101102312B (zh) | 一种网络通信数据处理方法、网络通信系统及客户端 | |
EP2438742B1 (en) | Method and node for distributing electronic content in a content distribution network | |
CN101331739B (zh) | 对等网络内容传输方法及装置 | |
US20110153835A1 (en) | System and method for controlling peer-to-peer connections | |
US20080059631A1 (en) | Push-Pull Based Content Delivery System | |
CN101080001B (zh) | 网络电视系统中用于实现媒体内容均衡的装置及其方法 | |
CN101304514B (zh) | 一种视频点播系统及其数据缓存方法和调度服务器 | |
CN102447624A (zh) | 在服务器集群上实现负载均衡的方法、节点服务器及集群 | |
US8150966B2 (en) | Multi-party cooperative peer-to-peer video streaming | |
CN101399746A (zh) | 报文路由方法、系统、设备和选择备份资源的方法、系统 | |
CN1937554A (zh) | 一种使p2p文件下载流量本地化的方法 | |
CN102387478B (zh) | 处理通讯系统中服务群组的所有权转换的方法及通讯装置 | |
CN101960793A (zh) | 分散式分层群集对等实况流系统 | |
CN101171803A (zh) | 数据网中带宽管理的方法和设备 | |
CN101662508B (zh) | 基于点对点协议数据传输的方法、装置和系统 | |
CN102158767B (zh) | 一种基于可扩展编码的对等网络流媒体直播系统 | |
CN101854287B (zh) | 一种p2p流量优化方法及装置 | |
CN105243078B (zh) | 一种文件资源的分发方法、系统和装置 | |
CN104158904A (zh) | 一种云辅助移动p2p网络协同下载方法 | |
CN101179705B (zh) | 伙伴资源节点选择方法和装置 | |
CN105577646A (zh) | 用户侧带宽聚合的方法、设备和内容分发系统 | |
CN101090367B (zh) | 一种对等网络中的数据传输方法及装置 | |
CN102404368A (zh) | 混合对等与主从式的数据传输架构与方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20120328 Termination date: 20150811 |
|
EXPY | Termination of patent right or utility model |