Octoshape是一个p2p流媒体服务器以及客户端, 使用点对点网格技术来尽可能的减少转播数据流所占用的带宽,从而达到让所有广播流媒体占用最小的带宽就能播放。Octoshape 采用HTTP 方式连接服务器,采用UDP 方式传输数据,默认UDP 端口为:554、5060。Octoshape是目前高清晰直播视频技术的领航者,它将为日益增多的网络高清直播提供解决方案。
Octoshape是一个p2p流媒体服务器以及客户端, 使用点对点网格技术来尽可能的减少转播数据流所占用的带宽。Octoshape是目前高清晰直播视频技术的领航者,它将为日益增多的网络高清直播提供解决方案。
实时流媒体本身及其应用正变得越来越流行,个人网络连接也正在快速扩展,并且还有部分网民在利用无线网线技术随时随地得接入互联网。实时流媒体的网络传播本身存在两个问题:规模和负载。它的挑战是在不增加网络负担的条件下,使用某种协议将单个网络资源同时传送给多个用户。实时流媒体的发展给网络传输造成很多技术上的难题,可以从Franc Kozamernik的著作中看到介绍,本文的焦点是在不增加网络负载的情况下传输大规模的实时流媒体数据。实时流媒体与下载播放和点播不同,它经过网络传输对事件现场进行直播。
本文将首先讨论实时流媒体传输的各种技术,包括比较传统的技术,研究规模和负载的问题是如何产生的,这样,我们就可以清楚的知道目前的技术是怎么解决问题的,最后将介绍Octoshape,它提供了一种较好的解决以上两个问题的方法,也将说明Octoshape是如何在这方面获得优势的。
1.规模和负载问题
上面已经提到规模和负载会引发一些问题。由于网络结构设计为点对点的传输文件,且文件只能在完全下载后才能使用或观看,这与一个数据源对应多个用户的无限传输理论的观点完全相反,所以问题在逐渐增加。举例来说,多个用户同时需要一个传播者的视频信号,那么这个单一的数据源就需要同时分别向多个用户传送数据,这就是为什么需要增加带宽(代表网络性能)来应付数据流增加所带来的网络负载。
进一步说,这也是负载很难均衡的原因。向多个网络用户同时分别传输数据造成了网络瓶颈,而网络瓶颈必然引起终端用户数据的不稳定,在最坏的情况下,用户会收到“服务器忙”的消息。虽然规模和负载的问题使实时流媒体的播放质量很难达到要求,但是网民对这种新兴的技术很感兴趣,要求也越来越高。
2.大规模实时流媒体传输的解决方案
某些技术对规模和负载所引发的问题采取不均衡的解决方法,这篇文章中,我们首先介绍这些较偏颇的解决方法,然后呈现Octoshape,并对它们进行对比。
到目前为止,网格技术有几种广泛应用,如P2P的文件共享程序BT,它提供电影和音乐文件共享,用户就可以使用多个数据源互相下载文件,这样就不会造成单方面网络负载的增加。文章的最后,我们将讨论Octoshape如何均衡提到的两个问题,来提供实时流媒体文件的,简单的说就是用较小的负载传播大规模的数据文件。虽然Octoshape只是一种解决方法,但是它仍然允许用户建立个人的共享网络。
2.1 媒体服务器:单播与平衡下载
单播是一种典型的实时数据流传输连接方式,如图1所示。这里,我们所指的结构使用一个或成群的服务器来管理用户请求数据,服务器群能够平衡机器下载并使这结构装更健壮,因为即使服务器群中的某台机器损坏,其它数据共享的服务器也可以向用户继续传送同样的数据,这样一种结构就称为媒体服务器,它所在网络的大小或其能力同样用带宽表示。举例来说,假设媒体服务器的网络带宽是100Mbit/s,那么一个100kbit/s的音频数据流理论上最多就可同时传送给1000个用户。一些大规模的传输网络拥有两个或三个媒体服务器,即便那样,带宽需求与用户数量仍然需要保持一定的比例,可用下面的公式表示:
Bandwidth_Needed = Size_of_Audience X Streaming_Quality
负载问题:传送两倍的数据需要两倍的带宽,要满足三倍的用户就需要三倍的带宽,换句话说,如果传送数据量增加或者用户增加,那么负载也一定会相应的增加。
规模问题:如果所有的数据都来自于同一个数据源(或两个),那么,这个连接点的带宽使用会很快达到它的上限,瓶颈问题与“服务器忙”的现象就会很快出现,这与早上同一家庭的所有成员同时出门去上班的现象相同,几个人不可能同时穿过一个门。这个问题很难解决,同时也说明为什么成倍的数据传输会引起成倍的带宽负载。
2.2 CDN:目前广泛使用的技术
CDN技术最初的目标是解决世界范围内的网络延迟问题,来有效掌控对同一网页同时的大量访问。它的主要思想是安置成千上万的机器,即边缘服务器,分布在世界范围的网络转换点上,同一个网页可以存储在这些边缘服务器上,这样,当用户请求这个网页的时候,就可以从最近的本地边缘服务器获取,结构如图2所示。这就增强了对同一资源可能的大量同时访问现象的掌控,同样也减小了文件下载所占用的带宽。现在,CDN技术也被用在实时流媒体传输上,有一部分公司目前正在提供类似的问题解决方法。
对实时流媒体传输问题的解决办法与对网页的处理是类似的,虽然上面只是对CDN技术的简单介绍,但是仍能明显看出,CDN技术比媒体服务器方式更具规模化,因为它旨在世界范围内分布成千上万的边缘服务器。尽管这样,资源共享也只对向边缘服务器请求相似资源的用户成立,因为大量的网络边缘机器不能本地化。例如,假设在英国发布一个大事件,CDN技术对英国范围以外的访问帮助不大,因为不管怎么处理,英国以外的网络访问都需要经过同一个转换网络进入英国。CDN技术能在一定范围内解决规模问题,但它不能解决负载问题,因为它引入了太多的机器。
2.3 多播:多地址传输同一数据
如果问五个人多播技术的定义,或许能得到多于七种不同的答案。这里,我们将介绍两种,希望能涵盖大部分的观点,在提供这两个定义之前,我们首先给出一个IP的确切定义。开车去一个确定的地方,就需要知道这个地方的明确地址。同样,在网上传输数据,也需要知道这个数据的目标地址,这个网络目标地址就称为IP地址。我们都知道,每台机器都使用自己的IP地址连接到网络,而数据流通过IP地址寻找传输路径与目标机器。
有些特殊的IP地址被预留出来为多播使用,这些地址被称为多播地址。使用多播的主要目的是传送数据时,可以通过一个地址一次传给多个用户,传送到多播地址的数据将同时传给在地址中标记的用户。多播的使用可追溯到20世纪80年代,当时人们为此付出了巨大的努力。虽然多播IP地址不是一个物理实体,但是它必须有硬件和软件的支持,最大的问题是什么使之成为可能?它是如何实现的?如果虚拟用户使用它将会发生什么?谁将为此负责?目前,如果交换机/路由器在本地网络中实现多播,那么企业内部使用多播将成为可能。
2.4 P2P流媒体传输:负载共享
使用前面描述的任何一种技术时,用户都只是接收数据却不会传出,即使这个用户既可以是单纯的用户也足够成为传播者。这就说明,前面的解决方法把重担都放在了终端上,即数据源一端,这将意味着虽然某个数据源用户的带宽使用达到极限,数据源用户却什么也没得到。
P2P流媒体传输的思想就是使终端用户能够使用空闲带宽,这样在数据源上的负载可用下面的公式表示:
Streaming_Quality X Audience_Size