流开发协议涉及的客户视频点播的分布

链接是如何工作的。

合作视频分配协议(<一个href="#B15">5)扩展了链接协议利用更大的缓冲区大小的现代客户因此,应该更好的命名扩展链接如果所有客户缓冲区足够大的存储整个视频中,服务器将不会传输视频数据超过视频消费率。

流攻(<一个href="#B2">6,<一个href="#B3">7),也被称为打补丁(<一个href="#B9">8),要求每个客户端机顶盒缓冲区能够存储至少10到15分钟的视频数据,并能接收数据的速度至少两次视频消费这个缓冲区将允许机顶盒“利用”为以前的客户最初创建的数据流,然后存储这些数据,直到他们需要在最好的情况下,客户获得的数据从现有的流。

特别是,流定义了两种类型的流。完整的流播放一段视频。充分挖掘流如果一个完整的流可以用于同样的视频开始吗β≤b几分钟过去,在那里b是客户端缓冲区的大小,单位为分钟的视频数据。在这种情况下,客户端开始接受完整的流,同时将数据存储在缓冲区,它收到一个完整的开发流,并使用它来显示第一个Δ分钟的视频。之后,客户端将使用直接从其缓冲流攻还定义了部分开发流时,可以使用Δ>β。在这种情况下,客户必须经过周期填充,然后清空缓冲区,由于缓冲区不够大占视频完全不同的位置。

使用挖掘流,客户只需要最多获得两个流在任何时候。客户可以接收数据视频消费的三倍速度可以使用一个选项的协议额外的攻。额外的开发允许客户从任何利用数据流在VOD服务器上,而不是仅仅从完整的流。图<一个href="//www.newsama.com/journals/am/2008/265309/fig2/" target="_blank">2显示了一些样本客户机请求的客户端一个是第一个客户端,它是由一个完整的服务流,其持续时间等于时间D的视频。因为客户端b到达分钟后客户端一个,它可以分享分钟的完整的流,只需要一个完整的开发时间分钟,最后,客户c可以使用额外的开发利用数据完整的流和前面的充分利用,所以其服务时间小于。

流开发是如何工作的。

渴望和弗农的动态的摩天大楼广播(双边带)<一个href="#B6">9)是另一个基于华和功能活性协议摩天大楼广播协议(<一个href="#B10">10,<一个href="#B11">11像摩天大楼广播,它从不要求新加坡旅游局同时收到两个多流更近分层多播流合并(HMSM)协议需要较少的服务器带宽比双边带处理相同的请求到达率(<一个href="#B5">12)其带宽需求确实是非常接近的最小带宽的上限活性协议不需要机顶盒接收两个多流同时,也就是说,

在哪里和是请求到达率。

选择性捕捉(<一个href="#B8">13)结合反应和积极的方法。它投入一定数量的渠道定期广播视频,在使用其他渠道允许传入请求赶上目前的广播周期。因此,它的带宽需求,在那里请求到达率和吗视频的时间。

3所示。我们的协议

链接和合作协议都需要客户发送视频数据的视频消费能力率结果,他们排除客户,上游带宽有限,说,不超过八分之一到四分之一的下游带宽,而这些客户可以下载视频数据的速度视频消费的两倍,他们可能只能在四分之一到一半的视频数据率。

我们想开发一个视频分销协议,它允许客户参与视频分布过程即使他们只能重新发送数据的一小部分视频消耗率(<一个href="#B12">14我们因此认为以下:

(1)客户能够接收视频数据在twic视频消费速度,(2)客户只能转发视频数据速率等于一小部分α相同的视频消费速度,(3)客户将无法多播视频数据,(4)客户就不会将视频数据转发后看完了视频,(5)客户应该有足够的缓冲空间来存储先前认为的部分视频观看,直到他们已经看完了它。

正如我们所看到的,我们的协议让一些要求客户端硬件的传播功能相反,它需要客户端缓冲区能够存储整个视频,也就是说,几个g的压缩视频数据这两个因素动机选择第一,各种存储的成本递减使这个要求比今天更加繁重的是几年前,第二,我们预期许多客户保持之前观看的部分他们看视频缓冲区提供相当于一个录像机回放功能。

我们的协议是一个相当简单的实现流攻没有额外的开发额外的开发需要客户能够接收视频视频消费的三倍速度只与原始流开发协议的不同之处在于它处理挖掘流的方式,同时利用流最初是服务器的唯一责任,现在的任务是由服务器和客户端共享b。让我们考虑图中所描述的场景<一个href="//www.newsama.com/journals/am/2008/265309/fig3/" target="_blank">3并专注于客户发行的请求c。让表示该请求之间的时间间隔和byclient发出请求b,,让表示时间开始以来的最后的请求由一个完整的服务流。

充分挖掘流是如何分布在服务器和以前的客户。

(1)如果≥D,这两个不重叠和客户机的请求c从最后一次完整不能利用任何数据流的原始流开发协议,服务器将启动一个新的完整的流。

(2)如果<D之间,有一个重叠的当前请求和最后完成流的原始流开发协议,服务器将评估是否更有利于防止利用最后一次完整流或开始一个新的如果服务器决定阻止利用最后一次完整流,它将必须提供客户端c充分挖掘流的持续时间现在应该考虑两种选择:

(一)如果、客户端b将提供一个分数α充分利用剩下的1 -流和服务器α流的一部分;(b)如果、客户端c将完成看视频之前能够传输所有的完整的开发流,只能发送一小部分充分挖掘流与服务器传输流的其余部分。

如果视频足够长,新请求可能会重叠超过一个先前的请求我们提出利用客户的可用带宽,发布这些请求,以进一步减少服务器的负载。这些客户的贡献将受到两个限制。首先,上游带宽限制防止客户端上传数据为两个不同的客户在同一时间。第二,我们永远不会要求客户端传输视频数据后端看完视频。

在我们的例子中,客户端请求形式一个完全是由一个完整的流从服务器请求来自客户端吗b得到最后一个分钟的视频,利用客户端一个完整的流和第一Δt分钟Δ全面挖掘流持续时间t一小部分α流的发送的客户一个,剩下的分数将来自服务器假定服务器决定不为客户开始一个新的完整的流c,客户将获得以下。

(1)最后一个分钟的视频,利用客户端一个完整的流。(2)一小部分α的第一个分钟的视频从一个水龙头流发送的客户一个;这水龙头流将结束时客户一个看完这个视频吗分钟后客户的到来c。(3)一小部分α的第一个分钟的视频从一个水龙头流发送的客户b;这水龙头流将结束时客户b看完这个视频吗分钟后客户的到来c。(4)的剩余部分分钟的视频服务器。

考虑最后一个问题是当停止利用从当前完成流和一个新的开始。To achieve this goal, our protocol keeps track of the minimum average request service time of all requests sharing the same complete stream Before adding a new request to a group, it computes what would be the new average request service time of the group if the new request was added to the group Should this new average request service time be lesser than or equal to the minimum average request service time of the group, our protocol adds the new request to the group; otherwise, it starts a new group This criterion is similar but not identical to that used by Carter and Long [<一个href="#B2">6,<一个href="#B3">7]。

3.1。处理客户端失败

正确操作,我们的协议要求所有客户视频数据转发给下一个客户为同一视频任何客户端失败会剥夺所有后续客户从他们的视频数据。

有一个简单的解决问题的办法让我们回到图的场景<一个href="//www.newsama.com/journals/am/2008/265309/fig3/" target="_blank">3,客户端c从客户接收大部分挖掘流一个和b,而客户端b从客户端接收几乎一半的挖掘流一个任何失败的客户端一个或客户b会立即影响正确的数据流到客户端c客户的失败一个需要服务器接管客户机的角色一个丢失的视频数据并将其发送给客户b和c。客户的失败b服务器上的工作负载的影响也会较少,这也将免费客户端吗一个从它的义务给客户端b一小部分的开发流,从而释放足够的上游带宽允许客户端一个接手客户的作用b和大部分丢失的视频数据发送给客户端c使协议服务器容错因此需要跟踪的客户是每个客户端发送视频数据。

4所示。绩效评估

评估我们的新协议的性能,我们设计了一个模拟的建模假设两个小时视频请求到达的分布可以由一个泊松过程建模<一个href="#B12">14]。基于类似模拟器用于以前的文件流开发和修改模型的客户,不能转发视频数据速率等于视频消费率(<一个href="#B14">15,<一个href="#B16">16]。

图<一个href="//www.newsama.com/journals/am/2008/265309/fig4/" target="_blank">4显示我们的新流的服务器带宽需求开发协议选择的值α和请求到达率不同一至每小时一千个请求带宽的倍数表达视频消费率此外,虚线代表服务器带宽需求的原始流开发协议额外开发让我们观察到两个协议之间的比较并不完全公平因为额外的开发需要客户能接收视频数据的视频消费率的三倍,而我们协议只需要客户端能接收视频数据率的两倍。

服务器带宽需求的新流开发协议。

我们可以看到,我们的新流开发协议优于传统流攻即使客户只能向前数据速率视频消费的四分之一,即当α= 0.25。这些结果是更好的比早期版本的协议,不允许客户接收视频数据从多个客户端<一个href="#B16">16]。

然而这个优良的性能在一个僵硬的价格显示在如图<一个href="//www.newsama.com/journals/am/2008/265309/fig5/" target="_blank">5,我们流开发协议的网络带宽需求增加更快比原始流开发协议当客户端请求到达率超过每小时十请求。这种现象可以解释在某种程度上,我们的协议不允许额外开发一个更重要的因素是服务器的方式决定何时开始一个新的完整的流。自客户处理大多数水龙头流,添加额外的请求服务器上的任何现有的集团有一个微不足道的影响工作结果,服务器从来没有开始一个新的流在年底前完成。因此挖掘流的平均持续时间等于一半的时间视频和网络带宽平均约等于1/2单播方案所需的带宽。

网络带宽需求的新流开发协议。

简单的解决这个问题将是限制水龙头流大小的一小部分β_马克斯视频的时间。这将减少这些(数据)流的平均持续时间和比例减少网络带宽。此解决方案,然而在low-arrival利率影响协议的性能,长挖掘流的惯例在调查其他几个选项,我们发现最好的办法是限制网络带宽的增长限制大小的水龙头流到达率高。与此同时,我们不想使服务器的设计,要求它保持一些移动平均为每个视频的请求到达率。

我们决定,而不是作为阈值的数量客户共享相同的完整的流和力服务器启动一个新的完整的流当水龙头流大小的(a)否则超过一小部分β_马克斯o的时间视频,和(b)以上请求已经分享当前完整的流。

数据<一个href="//www.newsama.com/journals/am/2008/265309/fig6/" target="_blank">6和<一个href="//www.newsama.com/journals/am/2008/265309/fig7/" target="_blank">7显示这个修改服务器和网络带宽的影响我们的协议。我们认为客户能够上传数据在四分之一视频消费率和设置β_马克斯到0.25。每个曲线对应于一个不同的值。我们看到水龙头流长度限制在四分之一的视频时间减少的一个因素4协议的网络带宽,同时增加到达率最高的服务器带宽相同的因素。即使在这种情况下,服务器带宽仍远低于原始流的开发协议。

服务器协议的带宽需求= 0。25,= 0。25。 协议的网络带宽需求= 0。25,= 0。25。

5。一个分析模型

在之前的文献[<一个href="#B17">17),我们认为流攻没有额外的开发视频的时间D正在访问速度λ。我们假设我们将启动一个新的完整的流的长度只要构成一个完整的利用超过了βD,0 <β≤1是一个参数来确定。

换句话说,我们将等待传入请求,开始一个完整的持续时间D,挖掘这个流持续时间的时间间隔βD,然后重新启动的过程。

在这段时间间隔,服务器将处理平均λβD除了要求促使完整的请求流因此请求共享相同的完整的流的平均数量

因为λ的长度βD充分挖掘流组将均匀分布在时间间隔(0,βD),每一种流的平均持续时间就等于βD/ 2的总持续时间所需的流处理这些1 +λβD请求将被

我们定义平均服务时间请求在一组的总时间W所需的流处理这些请求除以数量组的请求我们将

我们之前协议假定客户端与服务器将分享发送完整的点击流的任务γ≤1表示水龙头流的一部分,客户将能够发送。这个分数γ取决于两个因素α描述客户的上传带宽和以前客户的存在的重叠与当前请求的请求。当请求到来增加时,这些客户的数量也将增加,这将允许他们发送一个更大的部分γ的水龙头流。

对于一个给定的值γ请求,服务器的贡献平均服务时间

和以前的客户

发现价值β_选择的系数β减少服务器的负载,我们区分(<一个href="#eq2">5)对β,获得

唯一积极的根

当γ= 0,客户不参与发送完整的挖掘流,(<一个href="#eq2">5)恢复

当γ= 1,客户处理所有充分挖掘流,服务器只处理完整的流,β_选择→∞时结果,服务器不会开始一个新的完整的流在年底前前一个,和服务器带宽永远不会超过一个频道。

估计的总带宽需求的客户时,让我们考虑,让我们考虑一个间隔时间2D开始的开始一个新的完整的流在此时间间隔,该系统将得到平均2λD除了要求促使完整的请求流和客户将平均2λD充分挖掘流。因为这些充分挖掘流的长度会均匀分布在时间间隔(0,D),每一种流的平均持续时间就等于D/ 2的总持续时间因此将这些流

平均带宽使用的客户发送完整的水龙头流然后除以这个表达式给出的时间间隔,

总网络带宽需求我们的协议获得通过添加平均带宽服务器使用的表达式,我们可以看到图<一个href="//www.newsama.com/journals/am/2008/265309/fig4/" target="_blank">4,在大型的λ值非常接近。我们可以近似作为

比较这些需求与视频分布方案,不使用任何形式的多播了一个间隔的持续时间T,它将处理平均λT请求。因为每个请求将由一个单独的流服务的持续时间D,这些(数据)流的总持续时间将λDT,和的平均带宽需求计划将λD,也就是说,几乎平均带宽的两倍要求我们的合作开发协议。

数据<一个href="//www.newsama.com/journals/am/2008/265309/fig8/" target="_blank">8和<一个href="//www.newsama.com/journals/am/2008/265309/fig9/" target="_blank">9比较分析结果与仿真结果我们考虑两种极限情况γ= 0和γ= 1我们可以看出,两种模型预测的所有值相同的网络带宽 和所有到达率。

服务器带宽需求的新流开发协议。 网络带宽需求的新流开发协议。

这不是服务器带宽的情况下两种模型在实质性的协议α= 0或α≥0.5和不同意让我们考虑这三个病例。

(1)α= 0
当α= 0,客户不能上传视频数据因此,γ= 0和两个模型预测相同的网络带宽。

(2)
当,客户可以上传视频数据速度至少一半视频消费。因此,他们可以处理大多数,如果不是全部,水龙头流,他们的份额γ利用数据流的接近。这个不太适用于请求到达率低于每小时20请求,服务器还必须处理的一小部分水龙头流。

(3)
当,客户已经非常有限的上传带宽他们参与挖掘流的分布,但不能完全替代服务器只要请求到达率仍低于每小时60请求结果,0 <γ< 1和实际的服务器带宽站之间的值预测γ= 0和γ= 1。

让我们把我们的注意力转向的性能计划减少网络带宽消耗我们的协议在高到达率回想一下,这个计划是开始一个新的完整的流当水龙头流大小的(a)否则超过一小部分β_马克斯持续时间的视频,和(b)比请求已经分享当前完整的流。

平均,这个计划生效当请求到达率λ将超过一个阈值,

在高到达率时,服务器将启动一个新的完整的持续时间时间单位带宽需求将因此等于因此,服务器的平均带宽需求

现在让我们关注客户的行为在到达率大于或等于λ_马克斯再次假设,客户将处理所有充分挖掘流,他们将发送平均充分挖掘流每时间单位的平均长度等于这些水龙头流,平均带宽由客户端将使用

数据<一个href="//www.newsama.com/journals/am/2008/265309/fig10/" target="_blank">10和<一个href="//www.newsama.com/journals/am/2008/265309/fig11/" target="_blank">11我们的分析结果与仿真结果进行比较α= 0.25,β_马克斯= 0.25,和之前一样,这两个模型预测相同或接近相同的网络带宽的值 和所有到达率情况不是这样为服务器带宽这里我们分析模型低估了服务器带宽当请求到达率仍低于每小时60请求,因为它错误地假定客户机可以处理所有水龙头流。

服务器协议的带宽需求= 0。25,= 0。25,。 协议的网络带宽需求= 0。25,= 0。25,。

我们可以这样说,我们的概率分析结果证实那些通过模拟研究,得出合作流开发协议可以有效地利用集体上传带宽的客户即使每个客户不能上传视频数据超过四分之一的视频消费此外,要求服务器重启完成流以固定时间间隔提供一个有效的工具来限制网络带宽消耗的协议。

6。协议适用性

许多组织,如大学和公司运行自己的multicast-capable网络考虑当地的电话公司的例子,决定增加其服务包括按需服务的视频娱乐他们现有的许多客户已经订阅他们的高速互联网接入与我们的解决方案通过DSL,电话公司可以利用其multicast-enabled基础设施提供视频点播大量客户以非常低的成本。

7所示。结论

我们已经提出了一个流开发协议,涉及客户视频分配过程中我们的协议是根据multicast-capable环境中客户机能够下载视频数据视频消费的两倍速度但不一定转发视频数据率。我们观察到技术实现显著减少服务器的工作负载中请求到达率高,但也导致了更高的网络带宽消耗。这些增加但是可以控制要求服务器重启完成流在某个特定的间隔即使这样,协议的服务器带宽需求仍远低于纯客户端-服务器解决方案。

我们的建议与传统点对点(P2P)解决方案在两种不同的方法,它假定的存在一个或多个服务器能够多播视频数据的两倍到四倍的视频消耗率这允许协议更有效利用网络带宽的一个视频可以播放任意数量的客户第二,它不需要同行能够上传视频数据在四分之一到二分之一以上的视频消费利率,这将不可能在一个纯P2P等解决方案(<一个href="#B20">18)在纯P2P系统中,下载率呈正相关,上传速度一筹et al。<一个href="#B13">19]通过实验说明,上传的数据量非常接近bt等P2P系统中的数据下载(<一个href="#B1">20.]。因此,维持一个视频流服务,同行应该至少一个上传速度等于视频消费率。

流开发协议涉及的客户是一个很好的解决方案,尤其是在本地网络,因为它提供了一个可伸缩的方式分发高带宽视频点播流而过网络带宽。