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 – Used_Idle_End user_Bandwidth

P2P传输的过程是，一个传播者可以只向一个用户传输数据，而接收数据的用户接着可以再传给下一个用户，这样一直向下传输。理论上讲，一个传播者只传输给一个用户就可以拥有无数个用户，但是，技术上是无法实现较长用户链的。

事实上，基于用户传送能力的原则会起到一定的作用。一些软件公司，开源软件和学校工程正在使用这种方法，在它的理论指导下，基于树结构实现如下过程：一个传播者将数据传送给两个用户，这两个用户再分别传送给两个或更多用户，这样一直向下传输，如图4所示。用这种方法可避免前面提到的用户链过长问题，这种方式就称为P2P传输技术。P2P技术已经成功应用于10-100个同时操作的流媒体用户规模中，并且可使用服务器组对其进行扩展，小规模下的数据传输与较低的传播速率可将带宽需求降低40％－50％。

如图中看到的，P2P服务器似乎只输出两个数据流，几乎可能节省100％的带宽，但是，实际上是不可能的，下面我们作出解释：

（1） 终端用户需要输出与接收数据近似相等大小的数据流，但是，DSL只用于从服务器端向客户端传输，不能用于其它的方式，与此接近的一种方法是降低传播速率 。

（2） 在树结构中，大部分用户作为树的叶子存在于最低级别中，只能接收数据而不能向外输出，因此，大量用户中只有少数共同承担带宽的问题。

（3） 具体来说，当传播一个150kbit/s的数据流时，只有达到150kbit/s的用户才能为数据传输作出贡献，具有128kbit/s传输能力的用户根本起不到作用。

（4） 当某个用户关掉机器后，或许与其临近的正接收数据的用户会丢失数据源，P2P服务也必须重新构造树形式的网络结构。

在各种因素的影响下，很难建立一种健壮稳定的用于大规模的P2P数据服务结构，此外，将来这个问题会更加难以解决，原因是目前的P2P流媒体传输使用通信协议TCP，它不允许使用地址转换的用户(使用无线路由器)互相传输数据。

2．5 网状结构：用于大规模实时流媒体传输的Octoshape

Octoshape技术与传统的服务器技术相比节省了97％的带宽需求，这样就基本不存在带宽负载问题，也就不存在限制大规模化的瓶颈问题。为达到P2P树结构的目的，Octoshape使用插件减小传播者带宽的需求，达到使用户共同承担带宽的目的。Octoshape与广泛使用的文件共享程序相似，在详细介绍Octoshape技术之前，我们先看一下文件共享程序。

文件共享程序，如BT和Kazaa，广泛应用于电影和音乐类文件的共享，用户可以通过个人的PC机互相传输数据，包括数据请求与接收，实际上，根据报道，正是这些文件共享程序造成了70％的网络拥塞问题。BBC也正在测试以实现节目共享，它的重点就在限制带宽负载上，文件共享程序只能用于下载，而不能用于实时流媒体，如一段音乐，用户只能完全下载后才能正常播放。

服务器向用户传输数据后，用户可改变数据来减小带宽需求，一个用户不仅可以向多个用户同时传送数据，也可以同时从几个用户那里接收数据。能够同时从其它用户那里接收数据是Octoshape的目的，这对系统的整体效率是至关重要的。

在P2P树结构中，一个用户只能接收另一个用户的数据，但是Octoshape用户可以同时从多个用户1，2，3中接收数据。如图6所示：

这里仍然考虑用户互相传输数据的场景，在图6中，如果接收数据的用户要下载一部电影，那么向其传输数据的三个用户可分别向其传输电影的一部分，如电影中间或者最后30分钟的内容。Octoshape的两个特点是：

（1） 用户可以同时从多个用户中接收同一文件的不同部分。这就允许不同的用户同时向同一用户传输数据，能充分利用用户的下载能力。

（2） 如果某个正在传输数据的用户堵塞或者关机，文件的接收用户可以选择网络中的其它用户继续接收中断数据。通过这种方法，使用户独立于单一的数据源。

与用于文件下载相比，Octoshape技术用于实时流媒体传输比较困难。如果传输数据的用户关掉机器，它需要花费时间找到其它的数据传输用户，这对文件下载只是时间问题。但是，在实时流媒体传输中，这样会造成客户端媒体播放中断，直到找到其它合理的数据源。此外，为实时流媒体提供独立的网络也比较困难，用户不可能同时接收流媒体文件前面，中间或者最后的部分，因为对于实时流媒体文件来说，这些部分根本不存在。

Octoshape实时流媒体技术为使网络达到最大的效率包含很多方面的内容，下面我们对其中几项关键技术作出解释。一般音频或视频文件才会被作为实时数据流传输，而在实时数据流中，数据会按逻辑进行排序，没有两个数据是完全相同的。举例来说，假定实时流媒体文件的传输速率为400kbit/s，而每一个数据流的速率为100kbit/s，在Octoshape解决方式中，不同的数据流会按逻辑顺序重新排序，上面的例子中，用12个数据流描述一个画面，某用户接收到其中任意4个100kbit/s的数据流后，就可以用它们恢复出原始画面，这样就可实现用户对媒体的实时播放。如图7所示：

下面，我们把焦点放在网络数据用户上。在Octoshape技术中，每个终端用户都有属于自己的独一无二的数据流，因此不同的数据流个数就代表了不同的终端用户数，这些数据流以共享的方式存在，不会给传播者造成负担。每个用户既可以将自己的数据流传输给0，1，2，3，甚至更多的用户，也可以从其它用户那里接收100kbit/s的数据流，然后将这些数据流重新构造出原始的实时媒体文件。图8表示一个用户从四个用户那里接收数据后又传送给三个用户：

下面说明这些方面为什么能使网络达到最好的效率：

稳定的连接：终端用户一般都会维护一个相邻用户的连接表，每个终端用户都会不断向邻居发出请求以确认连接，一旦有用户堵塞或停止发送数据，可以及时找到替代用户。如果这个连接表太小，可以从地址簿中添加。

避免瓶颈问题：如果某个用户陷入堵塞，与其连接的用户会从连接表中找到其它用户代替，通过对连接的不断更新维护，用户就可避免瓶颈和堵塞问题。

不存在服务器的下载：既然每个用户都有地址簿和连接表，就没有必要在传送数据的用户中断后给服务器增加负担。

灵活使用带宽：用户通过减小传输实时流媒体的数据流大小来减小自己的网络负载，这样就使整个系统变得比较灵活。用户用低于媒体数据流大小的上传能力可上传较少的数据流，用户的上传能力较高或许可以上传更多的数据。为得到完全的灵活性，数据量与流的比率应该大于4，用户使用实时数据流的平均速率发送数据就可节省97％的带宽。

做到不可能的：假设一组用户使用某种方式连接在一起，与前面那个英国的例子类似，在一个地区或城市中，这组用户通过较小的网络连接在一起，某个用户需要向其它地区的用户传输数据，一般情况下，此网络中所有的用户都需要参与数据传输，而如果使用Octoshape技术，数据只需要传给组中的一个用户就可遍布其它用户。

如果用户都能做到尽量节省数据，有稳定的连接时不从服务器下载数据，就能减少本地甚至全球的网络堵塞与瓶颈问题，就能用较小带宽实现大规模数据传输，就能实现高质量的流媒体传输。