用于对等网络中的接收器驱动流传送的系统和方法

专利名称：用于对等网络中的接收器驱动流传送的系统和方法
技术领域：
本发明涉及用于松耦合对等(P2P)网络的接收器驱动P2P媒体流，尤其涉及用于在实时协调和客户机控制下将媒体从多个对等体流传送到客户机，而无需提供对等协作的系统和方法。
背景技术：
最近的市场研究指出，在2004年，美国有一半以上的因特网用户访问了某种形式的流媒体。访问流音乐是一种很流行的活动，而流视频的普及程度正在迅速增高。
不幸的是，与典型的网页不同，流媒体文件的尺寸通常极其大。例如，取决于所使用的编解码器，按2兆比特/秒(Mbps)来编码的3分钟的电影宣传片会产生45兆字节(MB)的媒体文件。流媒体必须解决的另一个问题是数据包传递的严格定时。因此，流媒体文件的大尺寸和数据包传递定时要求使典型的流媒体服务器设立和运行起来相对较昂贵。例如，一个当前的估算将用于流传送媒体的现行率定为每1GB的服务通信量是10美元。通过使用45MB文件大小的例子，这会导致被分发的每一电影宣传片有0.45美元的带宽成本。显而易见，随着媒体流量的增加，该成本会迅速上升。
对于媒体流的相对较高的成本的一个解决方案是使用“对等”(P2P)网络来将媒体流提供给个别的客户机。一般而言，P2P网络的基本理念是允许每个对等节点协助媒体服务器分发流媒体。用于流媒体的P2P网络的成功得到了用于实现P2P网络的大量常规途径。
例如，被称作“终端系统多点传送”和“PeerCast”的常规P2P方案使用用于媒体流的应用程序级多点传送(ALM)。具体地，利用ESM和PeerCast，这些对等节点被自我组织到现有IP网络上的覆盖树中。然后，沿该覆盖树来分发流数据。随后，在这些对等节点之间共享提供带宽的成本，从而减轻运行媒体服务器的带宽负担(因此减少美元成本)。然而，利用ESM和PeerCast，该分发树的叶节点只接收流媒体，而不促成内容分发。
两个其它的常规方案“CoopNet”和“SplitStream”通过使用跨越来源和对等节点的多个分发树，解决了诸如ESM和PeerCast等方案的内容分发局限。然后，CoopNet和SplitStream中的每个树可以发送流媒体的单独片断。结果，所有对等节点都可以涉及内容分发。
常规P2P媒体流解决方案的另一例子包括被称作“OStream”的流传送方案。OStream使用“高速缓存和中继站”方法，使得对等节点可以向客户机提供先前从其高速缓存分发的媒体。另一个常规系统“GnuStream”提供构建在公知的“Gnutella”系统之上的接收器驱动P2P媒体流系统。而被称作“CollectCast”的另一个常规方案积极地寻找最有可能实现最佳流传送质量的服务对等体，同时动态地自适应网络波动和对等体故障。
另一种类型的常规方案提供一种类型分布式文件共享，其中，文件的各个片断跨越许多对等体而被广泛的分发。然后，只要客户机请求下载该文件，就从多个对等体(而不是直接从服务器)服务该请求。例如，被称作“Swarmcast”的一个这样的方案通过将文件分成小得多的各个片断，来散布施加在提供流行的可下载内容的网站上的负载。一旦用户安装了该Swarmcast客户机程序，其计算机就通过分发(即供应)它们已下载的各个数据片断来自动与其它用户的计算机进行合作，从而减少中央服务器上的总服务负载。被称作“BitTorrent”的类似方案按照很类似的原则来运作。特别是，当在低负载情况时，使用BitTorrent方案来供应大型文件的网站将表现得很象典型的http服务器，因为它执行供应本身的大部分。然而，当服务器负载达到某个相对较高的水平时，BitTorrent将转变为大部分上传负担由用于供应其它下载客户机的下载客户机本身来承受的状态。
不幸的是，尽管诸如Swarmcast和BitTorrent等方案对于根据P2P网络规模分发各个文件片断以显著地增加服务器容量而言很有用，但这些系统不适用于有效率地流传送媒体。特别是，诸如Swarmcast和BitTorrent等方案不关心构成正被下载的一个或多个文件的数据包的传递的顺序或定时。这些文件仅仅逐段地从各对等体广播到客户机，然后仅仅按正确顺序在本地重新组装，以便在客户机计算机上重建原始文件。但是，在流媒体的情况下，必须仔细地考虑和控制数据包的定时和顺序，以便提供媒体的有效的流传送。
所以，需要一种系统和方法，用于从松散耦合的对等体集合到客户机的媒体流的接收器驱动控制。这种系统不应该要求各个对等体之间的通信或协作。另外，这种系统和方法应该通过要求客户机执行任何必要的计算操作的大部分，来将施加于对等体上的计算要求最小化。

发明内容
如这里所描述的“PeerStreamer(对等流传送器)”提供用于松散耦合P2P网络的接收器驱动对等(P2P)媒体流。网络中的对等体只执行简单的操作、可以高速缓存流媒体的全部或一部分、不与其它对等体协作、可以是不可靠的、并可以在任何给定的流传送会话期间脱机或联机。网络中的客户机(或接收器)进行实时操作，以便协调对等体、从多个对等体流传送媒体、执行负载平衡、处理对等体的联机/脱机状态、以及执行对流媒体的解码和呈现。
注意，这里所描述的PeerStreamer系统适用于具有多个客户机和对等体的大型P2P网络，但出于解释清楚的目的，下文将一般涉及个别客户机。本领域的技术人员将会理解，所描述的由PeerStreamer提供的系统和方法适用于多个客户机。此外，由于这里所描述的对等体用来将媒体供应给接收器或客户机，因此，P2P网络中的对等体群集在这里通常被称作“对等体”或“服务对等体”。也应该注意，如这里所描述的，这些“服务对等体”不应该与特定的流媒体文件最初所起源的“媒体服务器”混淆。
一般而言，PeerStreamer提供接收器驱动媒体流传送。PeerStreamer操作始于每个接收客户机检索保持所请求的流媒体的全部或一部分的附近的对等体的列表。注意，在该上下文中，媒体服务器也可以担当这些服务对等体之一。该列表包括IP地址、以及保持该服务媒体的完整或部分副本的一组一个或多个相邻服务对等体的监听端口。用于检索该列表的方法包括1)直接从媒体服务器中检索该列表；2)从已知的服务对等体中检索该列表；以及3)使用用于标识这些服务对等体的分布式散列表(DHT)方法。
一旦客户机检索了可用服务对等体列表，该客户机就连接到每个服务对等体，并获得其“可用性向量”。一般而言，每个服务对等体的可用性向量是该服务对等体所保持的媒体的确切部分的紧缩描述。然后，这些可用性向量由客户机用来确切地确定各个服务对等体保持该编码媒体的什么块。
例如，在特定的服务对等体保持全部服务媒体的情况下，该对等体的可用性向量可以是指出该服务对等体保持完整的媒体副本的单个标志。同样，如果服务对等体只保持服务媒体的一部分，那么该服务对等体的可用性向量将用信号通知客户机，服务对等体保持媒体的什么部分，例如，由服务对等体保持的每个数据包的块数以及块索引。
另外，在使用附加编码，例如以下所描述的各种擦除编码(erasure coding)技术的情况下，可用性向量将包括分配给服务对等体的媒体擦除编码关键字、以及由该服务对等体保持的擦除块的数目。此外，如果服务对等体使用擦除编码，并且，该媒体也被嵌入编码，那么，可用性向量将包括所分配的媒体擦除编码关键字、以及该嵌入编码所使用的不同的比特率水平处的每个数据包的擦除块的数目。
一般而言，已编码的媒体文件通常包括“媒体头部”，随后是表示所编码的媒体的多个媒体数据包(即“媒体主体”)。给定该可用性向量，下一步是让客户机检索媒体头部和“媒体结构”的长度，该媒体结构可从将要从对等体群集流传送的已编码媒体文件中导出。一组数据包的媒体结构仅仅是数据包头部加上数据包比特流长度。在检索了这些长度之后，客户机计算该媒体头部和媒体结构的“数据单元ID”，并按协作方式从该对等体群集中的一个或多个对等体中检索它们。
一旦媒体头部到达，客户机就分析该媒体头部，然后配置或初始化解码和呈现或回放正被流传送的特定类型的媒体(即MPEG 1/2/4、WMA、WMV等)所需要的任何音频/视频解码器和呈现设备。一旦完成了这个初始设置阶段，客户机随后就开始如下所述地协调正在进行的从对等体群集的媒体主体流传送。
具体地，给定特定流媒体的前述媒体结构，客户机计算流媒体(即媒体主体)的数据包的数据单元ID，然后逐个地检索那些数据包。在一个相关的实施例中，PeerStreamer使用嵌入编码媒体，然后，流传送比特率根据可用服务带宽和客户机队列状态而改变。在此情况下，媒体主体的媒体数据包的正在进行的检索对应于将基于可用带宽来提供最小的速率失真的那些数据包。
在任何一种情况下，客户机周期性地更新服务对等体列表，并连接到潜在的新服务对等体。在一个测试实施例中，客户机通过发出对于每个潜在的服务对等体的周期性常规TCP连接函数调用，来核对潜在的新服务对等体。在客户机建立与新服务对等体的连接之后，它首先检索前述可用性向量。然后，在接收器/客户机的方向上，该新对等体可以加入该群集中的其它活动对等体。然后，客户机协调这些对等体、根据其服务带宽和内容可用性来平衡这些对等体的服务负载、并将断开的或超时的对等体的无法履行的请求重定向到其它活动对等体中的一个或多个。然后，流传送操作按这个方式继续进行，直到全部流媒体被接收，或者流传送操作被用户停止。
在一个实施例中，PeerStreamer使用高速率擦除弹性编码，以允许多个服务对等体保持部分媒体而无冲突，以便客户机仅仅检索固定数目的擦除编码块，而不管在哪里检索和检索什么特定块。在此情况下，将所接收的擦除编码块放入客户机的分级队列，其中，媒体数据包随后被组装。然后，向下游发送被完全组装的媒体数据包，以便使用已为解码和呈现或回放正被流传送的特定类型的媒体而配置或初始化的任何音频/视频解码器和呈现设备来对它们进行解码和回放。在此情况下，通过控制分级队列的长度、请求队列的长度和压缩的音频/视频缓冲区的长度，客户机维持某段所需时期(在一个测试实施例中是4秒的数量级)的流缓冲区。然后，使用组合的缓冲区来防止网络数据包丢失和抖动。
鉴于以上概述，显而易见，这里所描述的PeerStreamer提供一种用于在P2P网络中提供接收器驱动媒体流传送的独特的系统和方法。除了刚刚描述的这些好处以外，通过下文中的详细描述并结合附图，PeerStreamer的其它优点也将会变得一目了然。


通过以下说明、所附权利要求书和附图，本发明的这些具体特征、方面和优点将得到更好的理解，附图中图1是描绘构成实现如这里所描述的“PeerStreamer”的示例性系统的通用计算设备的通用系统框图。
图2示出了用于如这里所描述的接收器驱动媒体流传送的示例性对等(P2P)网络。
图3提供示出用于实现如这里所描述的PeerStreamer的程序模块的示例性体系结构流程图。
图4示出了如这里所描述的流媒体文件的文件格式。
图5示出了如这里所描述的PeerStreamer的测试实施例中所使用的“数据单元”。
图6示出了如这里所描述的已被分成8个数据单元的嵌入编码媒体数据包的部分高速缓存。
图7提供了客户机PeerStreamer媒体流传送会话的示例DirectShowTM过滤器图表。
图8提供了表示如这里所描述的PeerStreamer请求和分级队列以及流媒体解码、呈现和回放的体系结构系统图，其系统缓冲区由虚线来示出。
图9提供了用于到达的数据单元的PeerStreamer客户机分级队列，以及用于每个服务对等体的PeerStreamer客户机请求队列的框解。
图10提供了示出如这里所描述的PeerStreamer的一个实施例的通用操作的操作流程图。
具体实施例方式
在本发明较佳实施例的以下描述中，参考附图，这些附图构成本发明的一部分，并且在这些附图中，通过举例说明，示出可以在其中实践本发明的特定实施例。可理解，在不脱离本发明的范围的前提下，可以利用其它实施例，并且可以进行结构上的更改。
1.0示例性操作环境图1示出了可以在其上实现本发明的合适的计算系统环境100的例子。计算系统环境100只是合适的计算环境的一个例子，它并不意在对本发明的使用范围或功能提出任何限制。也不应该将计算环境100解释为对示例性操作环境100中所示的任何一个组件或组件组合具有任何依赖性或要求。
本发明可用于众多其它的通用或专用计算系统环境或配置。可适用于本发明的众所周知的计算系统、环境和/或配置的例子包括，但不限于个人计算机、服务器计算机、手持式、膝上型或可移动计算机或通信设备(例如，蜂窝电话和PDA)、多处理器系统、基于微处理器的系统、机顶盒、可编程消费者电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。
本发明可以在诸如程序模块等由计算机结合硬件模块(包括话筒阵列198的各个组件)而执行的计算机可执行指令的一般上下文中描述。通常，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等。本发明也可以在分布式计算环境中实践，其中，任务由通过通信网络连接的远程处理设备来执行。在分布式计算环境中，程序模块可以位于包括存储器存储设备的本地和远程计算机存储介质中。参照图1，用于实现本发明的示例性系统包括计算机110形式的通用计算设备。
计算机110的组件可以包括，但不限于，处理单元120、系统存储器130和将包括系统存储器的各种系统组件耦合到处理单元120的系统总线121。系统总线121可以是几种类型的总线结构中的任一种，包括存储总线或存储控制器、外围总线、以及使用各种总线体系结构中的任一种的局部总线。作为示例而非局限，这类体系结构包括工业标准体系结构(ISA)总线、微通道体系结构(MCA)总线、增强型ISA(EISA)总线、视频电子技术标准协会(VESA)局部总线和外围部件互连(PCI)总线，也被称作Mezzanine总线。
计算机110通常包括各种计算机可读介质。计算机可读介质可以是可由计算机110访问的任何可用介质，它包括易失性和非易失性介质、可移动和不可移动介质。作为示例而非局限，计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于诸如计算机可读指令、数据结构、程序模块或其它数据等信息的存储的任何方法或技术来实现的易失性性和非易失性、可移动和不可移动介质。
计算机存储介质包括，但不限于RAM、ROM、PROM、EPROM、EEPROM、闪存或其它存储器技术；CD-ROM、数字多功能盘(DVD)、或其它光盘存储器；盒式磁带、磁带、磁盘存储器、或其它磁性存储设备；或可以用来存储所需信息并可以由计算机110访问的其它任何介质。通信介质通常具体表现为诸如载波或其它传输机制等已调制数据信号中的计算机可读指令、数据结构、程序模块或其它数据，它包括任何信息传递介质。术语“已调制数据信号”指其一个或多个特征按为信号中的信息编码的方式来加以设置或更改的信号。作为示例而非局限，通信介质包括有线介质，例如，有线网络或直线连接，和无线介质，例如，声学、RF、红外线和其它无线介质。以上任何内容的组合也应该被包括在计算机可读介质的范围以内。
系统存储器130包括易失性和/或非易失性存储器形式的计算机存储介质，例如只读存储器(ROM)131和随机存取存储器(RAM)132。基本输入/输出系统133(BIOS)通常存储在ROM 131中，它包含例如在启动期间有助于在计算机110内的各个元件之间传送信息的基本例程。RAM 132通常包含可立即由处理单元120访问和/或目前正由处理单元120操作的数据和/或程序模块。作为示例而非局限，图1示出了操作系统134、应用程序135、其它程序模块136和程序数据137。
计算机110也可以包括其它可移动/不可移动、易失性/非易失性计算机存储介质。仅作为示例，图1示出了从不可移动非易失性磁性介质读取或对其写入的硬盘驱动器141、从可移动非易失性磁盘152读取或对其写入的磁盘驱动器151，以及从可移动非易失性光盘156(例如，CD ROM或其它光学介质)读取或对其写入的光盘驱动器155。可以用于示例性操作环境中的其它可移动/不可移动、易失性/非易失性计算机存储介质包括，但不限于，盒式磁带、闪存卡、数字多功能盘、数字录像带、固态RAM、固态ROM等。硬盘驱动器141通常通过不可移动存储器接口，如接口140连接到系统总线121，磁盘驱动器151和光盘驱动器155通常由可移动存储器接口，如接口150连接到系统总线121。
以上所讨论的和图1中所示出的这些驱动器及其相关联的计算机存储介质为计算机110提供计算机可读指令、数据结构、程序模块和其它数据的存储。例如，在图1中，硬盘驱动器141被示为存储操作系统144、应用程序145、其它程序模块146和程序数据147。注意，这些组件可以与操作系统134、应用程序135、其它程序模块136和程序数据137相同或不同。这里为操作系统144、应用程序145、其它程序模块146和程序数据147提供不同的标号，以说明它们至少是不同的副本。用户可以通过输入设备，例如键盘162和定点设备161(通常指鼠标、跟踪球或触摸垫)，来将命令和信息输入到计算机110。
其它输入设备(未示出)可以包括操纵杆、游戏垫、圆盘式卫星天线、扫描仪、无线电接收器、以及电视或广播视频接收器、或类似的输入设备。这些和其它输入设备经常通过耦合到系统总线121的有线或无线用户输入接口160连接到处理单元120，但也可以由其它常规接口和总线结构连接，例如，并行端口、游戏端口、通用串行总线(USB)、IEEE 1394接口、BluetoothTM(蓝牙)无线接口、IEEE 802.11无线接口等。另外，计算机110也可以包括经由音频接口199连接的语音或音频输入设备，例如话筒或话筒阵列198，以及扩音器197或其它声音输出设备，音频接口199也包括常规的有线或无线接口，例如并行、串行、USB、IEEE 1394、BluetoothTM等。
监视器191或其它类型的显示设备也经由接口，如视频接口190连接到系统总线121。除监视器以外，计算机也可以包括其它外围输出设备，如打印机196，它们可以通过输出外围接口195来连接。
计算机110可以使用与一台或多台远程计算机，如远程计算机180的逻辑连接而在联网环境中操作。远程计算机180可以是个人计算机、服务器、路由器、网络PC、对等设备或其它普通网络节点，它通常包括以上相对于计算机110而描述的许多或所有元件，尽管图1中只示出了存储器存储设备181。图1中所描绘的逻辑连接包括局域网(LAN)171和广域网(WAN)173，但也可以包括其它网络。这类联网环境在办公室、企业范围计算机网络、内联网和因特网中很普遍。
当用于LAN联网环境中时，计算机110通过网络接口或适配器170连接到LAN 171。当用于WAN联网环境中时，计算机110通常包括调制解调器172或用于通过WAN 173(例如，因特网)建立通信的其它装置。调制解调器172可以是内置或外置的，它可以经由用户输入接口160或其它适当的机制连接到系统总线121。在联网环境中，相对于计算机110而描绘的程序模块或其各个部分可以被存储在远程存储器存储设备中。作为示例而非局限，图1将远程应用程序185示为驻留在存储器设备181上。将会理解，所示的网络连接起示例性的作用，可以使用在计算机之间建立通信链路的其它装置。
现在已讨论了示例性操作环境，本描述的剩余部分将致力于讨论实施“PeerStreamer”的程序模块和过程，该“PeerStreamer”提供对用于分布式媒体流传送的接收器驱动对等(P2P)网络中的一个或多个对等体的群集的动态实时客户机控制。
2.0引言如这里所描述的“PeerStreamer”提供用于松散耦合P2P网络的接收器驱动对等(P2P)媒体流传送。该网络中的对等体只执行简单的操作、可以高速缓存流媒体的全部或一部分、不与其它对等体协作、可以是不可靠的、并可以在任何给定的流传送会话期间脱机或联机。该网络中的客户机进行实时操作，以便协调对等体、从多个对等体流传送媒体、执行负载平衡、处理对等体的联机/脱机状态、以及执行对流媒体的解码和呈现。
注意，这里所描述的PeerStreamer系统适用于具有多个客户机和对等体的大型P2P网络，但出于解释清楚的目的，下文将通常涉及个别的客户机。本领域的技术人员将会理解，由PeerStreamer提供的所描述的系统和方法适用于多个客户机。此外，由于这里所描述的对等体用来将媒体供应给接收器或客户机，因此，P2P网络中的对等体群集在这里通常被称作“对等体”或“服务对等体”。也应该注意，如这里所描述的，“服务对等体”不应该与特定流媒体文件最初所起源的“媒体服务器”混淆。
一般而言，PeerStreamer在诸如图2所示的网络等P2P网络中操作。对于特定的流传送会话，“服务器”200被定义为P2P网络中最初发起流媒体的节点；“客户机”(或接收器)210被定义为当前请求流媒体的节点；并且，“服务对等体”220被定义为向客户机供应流媒体的完整或部分副本的节点。
一般而言，服务器200、客户机210和服务对等体220都是与诸如因特网等网络连接的最终用户节点。由于服务器200总是能够供应流媒体，因此，服务器节点也担当服务对等体220。服务器节点200也可以执行无法由服务对等体220执行的媒体管理功能，例如，维持可用服务对等体的列表、执行数字权限管理(DRM)功能等等。此外，对于常规的P2P方案，当部署越来越多的流对等体节点220时，这里所描述的PeerStreamer会得益于效率的提高。特别是，随着流对等体节点220的数目的增加，媒体服务器200上的负载将会减少，从而运行起来费用不会太大，同时，每个客户机节点210将能够在特定媒体流传送会话期间接收好得多的媒体质量。
此外，应该显而易见，对于许多其它P2P类型的网络，特定节点的角色可能会改变。例如，特定节点可以在一个特定的流传送会话中担当客户机210，同时，在另一个会话中担当服务对等体220。另外，特定节点可以同时担当客户机节点210和服务器200或服务对等体220，以便同时流传送一个或多个媒体文件或媒体文件的各个部分，同时，从一个或多个其它服务对等体接收其它流媒体。
在流传送会话期间，客户机200首先定位保持部分或全部所需媒体的多个靠近的对等体220，然后从这多个对等体(可以包括服务器200)流传送媒体。因此，每个服务对等体220通过服务客户机210的下载请求的一个部分，来协助服务器200减轻总上传负担。结果，尤其在有许多客户机的情况下，客户机210经常可以接收好得多的流媒体质量，因为当有许多流对等体220来协助服务器200时，有大得多的服务带宽可用。
对于任何P2P网络，每一个别的对等体220不直接得益于服务一个或多个客户机210。但是，在一个实施例中，常规的P2P“公平机制”用来确保，与在担当服务对等体的过程中还没有平等地合作的另一个对等体相比较，合作对等体220在供应随后的流请求方面接收更高的优先级。因此，当利用PeerStreamer来实现这种公平机制时，合作对等体220通常可以期待在下一次它变成客户机210时会有更好的媒体质量。
因此，认识到每个服务对等体220在任何特定的流传送会话期间有效地支持客户机210和服务器200的事实，良好的设计原理是确保服务对等体是轻量级的，且P2P网络是松散耦合的。换言之，服务对等体220应该只需要执行具有低CPU负载的最简单的操作。另外，在一个实施例中，服务对等体220也可以选择只高速缓存媒体的一部分，以便将本质上由每个服务对等体贡献的存储空间减到最小。此外，为了降低各个对等体220之间的通信的任何带宽成本，不应该要求每个服务对等体与其它对等体协作。最后，运行于任何特定的服务对等体220上的其它程序可以对在任何特定的时刻在要求CPU和网络资源方面具有更高的优先级，或者，特定的对等体可以在任何时候只是简单地被打开或关闭。结果，特定的服务对等体200可以是不可靠的，可用的服务带宽方面有波动。实际上，在流传送会话期间的任何时候，特定的服务对等体可以简单地脱机或联机。
相反，在客户机210上增加负担，以便将资源投入于流传送会话是公平合理的。具体地，客户机210需要从多个对等体220接收该流媒体，所以，它被连接到这些对等体。另外，客户机210有动力来有效地协调或管理对等体200，以便改善其自己的流传送体验。因此，这里所描述的PeerStreamer系统和方法利用对松散耦合的P2P网络中的服务对等体的接收器驱动控制，其中，客户机负责在各个流对等体之中发送和协调数据包请求。
2.1系统纵览如上所述，这里所描述的PeerStreamer提供一种用于松散耦合的P2P网络的接收器驱动对等(P2P)媒体流传送系统和方法。该网络中的对等体只执行简单的操作、可以高速缓存流媒体的全部或一部分、不与其它对等体协作、可以是不可靠的、以及可以在任何给定的流传送会话期间脱机或联机。该网络中的客户机(或接收器)进行实时操作以便协调对等体、从多个对等体流传送媒体、执行负载平衡、处理对等体的联机/脱机状态、以及执行对流媒体的解码和呈现。
一般而言，PeerStreamer提供接收器驱动媒体流传送。PeerStreamer操作始于每个接收客户机检索保持有所请求的流媒体的全部或一部分的附近的服务对等体的列表。注意，在该上下文中，媒体服务器也可以担当服务对等体之一。该列表包括保持服务媒体的完整或部分副本的一组一个或多个相邻服务对等体的IP地址以及监听端口。用于检索这个列表的方法包括1)直接从媒体服务器中检索该列表；2)从已知的服务对等体中检索该列表；以及3)使用用于识别服务对等体的分布式散列表(DHT)方法。
一旦客户机检索到可用服务对等体列表，该客户机就连接到每个服务对等体，并获得其“可用性向量”。一般而言，每个服务对等体的可用性向量是每个服务对等体所保持的媒体的确切部分的紧缩描述。然后，该可用性向量被客户机用来确切地确定服务对等体保持已编码媒体的什么块。
例如，在特定服务对等体保持全部服务媒体的情况下，该对等体的可用性向量可以是指出该服务对等体保持完整的媒体副本的单个标志。同样，如果服务对等体只保持服务媒体的一部分，那么，该服务对等体的可用性向量将用信号通知客户机，该服务对等体保持媒体的什么部分，例如，由该服务对等体保持的每个数据包的块数以及块索引。
另外，在使用诸如以下所描述的各种擦除编码技术等附加编码的情况下，可用性向量将包括分配给服务对等体的媒体擦除编码关键字、以及由服务对等体保持的擦除块的数目。此外，如果服务对等体使用擦除编码，并且该媒体也被嵌入编码，则可用性向量将包括所分配的媒体擦除编码关键字、以及该嵌入编码所使用的不同比特率级别处的每个数据包的擦除块的数目。
给定可用性向量，下一步是让客户机检索将要从对等体集群流传送的媒体的“媒体头部”和“媒体结构”的长度。在检索了这些长度之后，客户机计算媒体头部和媒体结构的“数据单元ID”，并且，作为已分析了每个服务对等体的可用性向量的结果，根据对于什么对等体具有什么数据包ID的了解，来从对等体集群内的一个或多个对等体中检索它们。
一旦媒体头部到达，客户机就分析该媒体头部，然后配置或初始化解码和呈现或回放正被流传送的特定类型媒体(即MPEG 1/2/4、WMA、WMV等)所需要的任何音频/视频解码器和呈现设备。一旦完成了该初始设置阶段，客户机随后就开始协调从如下所述的对等体群集的正在进行的媒体主体的流传送。特别是，给定特定流媒体的前述媒体结构，客户机计算该流媒体的数据包的数据单元ID，然后从各个对等体中逐个检索那些数据包。
然后，客户机周期性地更新服务对等体列表(使用用于识别服务对等体的前述方法之一)，并连接到潜在的新服务对等体。在一个测试实施例中，客户机通过发出对于每个潜在的服务对等体的周期性常规TCP连接函数的调用，来核对潜在的新服务对等体。在客户机建立与新服务对等体的连接之后，它首先检索前述可用性向量。然后，在接收器/客户机的方向上，该新对等体可以加入群集中的其它活动对等体。然后，客户机协调这些对等体、根据其服务带宽和内容可用性来平衡这些对等体的服务负载、并将对断开的或超时的对等体的无法履行的请求重定向到其它活动对等体中的一个或多个。然后，流传送操作按这个方式继续进行，直到全部流媒体被接收，或者该流传送操作被用户停止。
2.2系统体系结构纵览以上概述的过程由图3中的通用系统框图来示出。具体地，如这里所描述的，图3中的系统框图示出了用于实现PeerStreamer的程序模块之间的相互关系。应该注意，由图3中的折线或虚线来表示的任何方框以及方框之间的互连表示这里所描述的PeerStreamer的替换实施例；并且，如下所述，可以结合在这整个文档中描述的其它替换实施例来使用任何或所有这些替换实施例。
一般而言，通过让客户机使用对等体位置模块305来检索或识别保持所请求的流媒体的全部或一部分的附近的服务对等体220的列表310，PeerStreamer开始对于每个客户机210的操作。注意，在该上下文中，媒体服务器200也可以担当服务对等体220之一。对等体位置模块305使用各种方法来检索对等体列表310。例如，在一个实施例中，直接从服务器200提供对等体列表310。在另一个实施例中，从已知的服务对等体220中检索对等体列表310。最后，在又一个实施例中，对等体位置模块305使用常规的分布式散列表(DHT)来识别服务对等体220。如上所述，对等体列表305包括保持服务媒体的完整或部分副本的一个或多个相邻服务对等体220的IP地址以及监听端口。
服务媒体本身由存在于服务器200上的媒体编码模块300通过使用多种常规编解码器(包括例如MPEG 1/2/4、WMA、WMV等)中的任何一个来进行编码。注意，如这里进一步详细描述的，用来为媒体编码的编解码器可以是嵌入的或非嵌入的。另外，在一个实施例中，如以下进一步详细描述的“高速率擦除弹性编码”结合任何编解码器来使用，以提供对本质上不可靠的服务对等体220的提高的健壮性。
最初，所编码的媒体只存在于最初在其上为该媒体编码的服务器上。然后，它全部或部分地被分发给服务对等体220中的一个或多个(再一次，服务器200也可以担当用于媒体流传送用途的服务对等体)。对服务对等体220的分发要么是媒体流的数据包对对等体的直接分发的结果；要么作为当媒体最初被流传送到该服务对等体时令已流传送该媒体的一个或多个对等体(当担当客户机210时)仅仅高速缓存该媒体的全部或一部分的结果。在任何情况下，出于解释的目的，假设有多个已知的对等体(如对等体列表310所定义的)，并且，每个对等体保持将要流传送的已编码媒体的全部或一部分。
一旦客户机210检索了可用服务对等体的列表310，该客户机就经由从每个对等体中检索前述可用性向量的可用性向量检索模块320连接到每个服务对等体220。接下来，给定每个对等体320的可用性向量的信息，客户机210随后使用媒体头部/媒体结构分析模块325来检索关于将要从对等体群集220流传送的媒体头部和媒体结构的“媒体头部”和“媒体结构”的长度。在检索了这些长度之后，客户机210分析该媒体头部，然后使用客户机配置模块330来配置或初始化解码和呈现或回放正被流传送的特定类型媒体(即MPEG 1/2/4、WMA、WMV等)所需要的任何音频/视频解码器和呈现设备。
此外，媒体头部/媒体结构分析模块325也根据该媒体结构和媒体头部的分析来确定，在对将要流传送的媒体进行编码的过程中，是否已使用嵌入编码媒体或高速率擦除弹性编码中的任何一项或两项。
然后，数据单元ID计算模块335用于基于媒体头部和媒体结构中所包括的信息来计算流媒体的数据包的“数据单元ID”。然后，数据单元请求模块340使用所计算的数据单元ID向对等体群集220中的各个对等体请求流媒体的特定数据包或数据块。
在PeerStreamer使用嵌入编码媒体的情况下，如以下进一步详细描述的，流传送比特率根据可用的服务带宽和客户机队列状态而改变。在此情况下，由数据单元请求模块340提出的对于媒体数据包或数据单元的检索的正在进行的请求对应于将基于可用带宽来提供最小的速率失真的那些数据包(或数据块)。另外，在使用高速率擦除弹性编码的另一情况下，多个服务对等体保持部分媒体而无冲突，以便客户机仅仅检索固定数量的擦除编码块，而不管在哪里检索和检索什么特定的块。
在任何情况下，当客户机210经由数据单元处理模块345来检索媒体的流传送块时，该客户机将会要么如下所述那样传递将要被解码的那些数据包，要么数据单元处理模块将首先从数据块重建该媒体流的数据包(见以下关于高速率擦除编码的讨论)。此外，客户机210将周期性地更新服务对等体列表310(使用用于识别服务对等体的前述方法之一)。无论何时或按某个所需的频率更新了列表310，客户机210将连接到潜在的新服务对等体，以检索前述可用性向量。然后，在接收器/客户机210的方向上，该新对等体可以加入群集220中的其它活动对等体。
然后，客户机210协调对等体320、根据其服务带宽和内容可用性来平衡这些对等体的服务负载、并将断开的或超时的对等体的无法履行的请求重定向到其它活动对等体中的一个或多个。然后，流传送操作按这个方式继续进行，直到全部流媒体经由解码/呈现/回放模块350而被接收、解码、呈现和回放。注意，经由常规的显示设备355和/或扬声器360来提供已解码媒体的回放，向这些显示设备355和/或扬声器360提供其来自解码/呈现/回放模块350的输入。
3.0操作纵览上述程序模块用于实现PeerStreamer。如以上概述，PeerStreamer提供用于松散耦合的P2P网络的接收器驱动对等(P2P)媒体流传送。以下各个章节详细讨论PeerStreamer的操作、以及用于实现根据图2而在章节2中描述的程序模块的示例性方法。特别地，在详细描述以下在章节3.1和3.2中所提供的PeerStreamer操作之后，在图10中呈现操作流程图，它鉴于该详细描述来概述PeerStreamer的总操作。
3.1PeerStreamer的操作细节以下各段详述这里所描述的PeerStreamer的特定操作实施例和替换实施例。具体地，以下各段描述PeerStreamer所使用的“流媒体模型”；所请求的流媒体的“媒体结构”(基本上是定义计算用于检索媒体数据包或“数据单元”的数据ID所需要的流媒体的特征的“伴随文件”)；表示用于流传送的媒体数据包的固定尺寸部分的PeerStreamer数据单元；用于降低存储要求的媒体的局部高速缓存；用于提高PeerStreamer系统对本质上不可靠的服务对等体的健壮性的媒体的高速率擦除编码。
3.1.1流媒体模型一般而言，流媒体包括当到达时被解码和呈现的数据包流(因此具有名称流传送)。若无流传送，在可以使用它之前，必须以一个大块下载全部媒体。在图4中，示出了PeerStreamer所使用的流媒体文件的通用结构。
具体地，如图4所示的，媒体由“媒体头部”来引导，它包含描述该媒体的全局信息，例如，该媒体中的通道数目、每个通道的属性和特征(音频采样率、视频分辨率/帧速率)、所使用的编解码器、该媒体的作者/版权持有者等。通常在流传送会话开始之前下载媒体头部，以便客户机可以设立这些必要的工具来对随后接收的数据包进行解码和呈现。注意，流媒体可以包括几个通道，其中每个通道是可以被独立地选择和解码的单独的媒体分量，例如，英语音轨、西班牙语音轨、4∶3视频、16∶9视频等。
媒体头部后面是媒体数据包序列，其中每个媒体数据包包含跨越短时期的某个通道的压缩比特流。每个媒体数据包由数据包头部来引导，它包含诸如通道索引、数据包的起始时间标记、数据包的持续时间、以及标志数量等信息，例如，该数据包是否是关键帧(例如，MPEG I帧)、该数据包是否是嵌入编码的数据包(具有可截断的比特流)等等。然后是数据包的压缩比特流。
如今大多数的常规压缩媒体编解码器(例如，MPEG1/2/4音频/视频、WMA/WMV、RealAudio/Realvideo等)生成非嵌入的编码媒体数据包。因此，无法更改这类系统所生成的媒体数据包的大小。而且，只要这一比特流中的媒体数据包之一被丢失或被过度延迟，结果都是，要么该媒体不是可解码的，要么该回放变得紊乱或间断，从而降低流媒体的回放质量。为了保持与这些常规编解码器相兼容，在一个实施例中，PeerStreamer系统和方法允许媒体数据包是非嵌入编码的(不可缩放)。但是，除了支持传统的压缩媒体格式以外，PeerStreamer在一个实施例中也支持嵌入的编码媒体。
利用嵌入的编码媒体，每个媒体数据包按可以被独立地向后截断的方法来编码。一般而言，两种类型的嵌入编码得到PeerStreamer的支持——位平面编码和增强层编码。注意，对本领域的技术人而言，这两种类型的嵌入编码都是公知的。因此，在以下各段中，将只概括地描述这些编码。
例如，利用位平面编码，通常通过逐个位平面地(从最高位平面(MSB)到最低位平面(LSB))对音频/视频变换系数块进行编码，来实现媒体块的可缩放编码。如果在编码之后截断比特流，那么，为所有这些系数的最高位平面中的几个保留该信息。而且，被截断的比特流对应于较低比特率的压缩比特流，它可以被认为是嵌入在较高比特率压缩的比特流中，因而是具有名称嵌入编码。结果，可以截断该嵌入编码器所生成的媒体数据包，具有适度的速率-失真折衷。
利用增强层编码，媒体内容被压缩成基层以及一个或多个增强层，其中每个层通常占据单独的通道。具体地，这类编码允许将要接收的最低质量媒体流预订该基层。随着每个接连的增强层的添加，解码的媒体质量得到改善。因此，利用这类系统，取决于可用带宽，并通过预订基层和尽可能多的增强层，接收器或客户机通常可优化所接收的信息的质量。
3.1.2PeerStreamer媒体结构为了在接收器驱动模式中进行操作，PeerStreamer客户机需要知道将要被请求的媒体数据包的结构，以便它可以知道向每个对等体请求什么数据包和每个数据包的什么部分。该信息在一“伴随文件”中提供，该“伴随文件”包括将要被请求的流媒体的结构的定义。一般而言，该媒体结构为PeerStreamer客户机提供整个媒体的概观(例如，每个数据包的起始时间标记、每个数据包的持续时间等)，以便它可以智能地计划P2P流传送会话，并确保特定的媒体数据包及时到达以供解码和呈现。注意，在原先为媒体文件编码时，最初生成包含媒体结构信息的伴随文件；然后，该伴随文件在每个流传送会话的起始处请求时，连同该媒体头部的初始请求一起被流传送到客户机。注意，在由常规编解码器为该媒体编码之后，通过分析该媒体头部和数据包头部，也可以生成伴随文件中的信息。
具体地，一组数据包的媒体结构由数据包头部加上数据包比特流长度组成。因此，该信息可以由客户机用来确定应该请求哪些特定的数据包、应该请求那些数据包的时间、以及应该向其请求那些数据包的对等体。因此，PeerStreamer在流“设置”阶段首先检索全部媒体的媒体结构。通过在实际上流传送媒体之前检索信息，可引起流设置中的小延迟。但是，通过在媒体流传送之前首先检索信息，在带宽方面没有用于将媒体结构信息供应给客户机的额外成本(在媒体流传送期间)。
注意，相对于流媒体的总长度而言，起始流中的前述延迟通常很小。例如，在PeerStreamer的一个测试实施例中，大小范围从31兆字节(MB)到49MB的五个测试影片剪辑具有在大约37千字节(KB)至大约53KB的范围内的媒体结构伴随文件。所以，观察到，该媒体结构大小是总媒体主体的大约0.10-0.15％的数量级。所以，假设服务带宽大于或等于媒体比特率，并且媒体结构是媒体主体的0.15％，那么，下载10分钟剪辑的媒体结构会引起少于0.9s的额外的延迟。
在一个相关实施例中，为某个预定长度(即10秒、30秒、1分钟等)的顺序媒体段生成局部媒体结构。然后，在对应的媒体段将要在不远的将来被流传送之前，只检索每个局部媒体结构。这略微增加带宽要求，因为媒体结构请求和传输可以与媒体数据包请求和传输共存。但是，由于媒体结构的大小在此情况下是如此小，因此，通常可以忽略对全部带宽要求的影响。
3.1.3PeerStreamer数据单元在一个实施例中，PeerStreamer将媒体数据包、媒体头部和媒体结构分成长度为L的各个固定大小数据单元。使用固定大小数据单元的原因是，PeerStreamer客户机和服务对等体随后可以预先分配大小为L的存储器块，从而在流过程期间避免费用昂贵的存储器分配操作。另外，通过将媒体数据包(潜在地说，很大)分成小的固定大小数据单元，也可允许PeerStreamer客户机将服务负载分配给具有较小粒度的对等体，从而在这些对等体之中实现更好的带宽负载平衡。
一般而言，通过将每个数据包分成 个数据单元，来将长度为P的数据包(可以是媒体数据包、媒体头部或媒体结构)分成大小为L的块，其中， 是返回大于或等于x的最小整数的常规天棚函数。于是，所有数据单元具有固定长度L，潜在地除每个数据包的最后一个的数据单元以外(其长度是P mod L)。
在使用媒体的非嵌入编码的情况下，在网络传输期间，不能丢弃构成每个媒体数据包的数据单元而不降低媒体回放质量。所以，这些数据包被指定为“必要数据单元”，因为它们都必须加以接收。
相反，当嵌入编码媒体数据包被分成各个数据单元时，只有基层数据单元必须被传递，并且，如果服务带宽不足够，那么，可以随意地丢弃剩余的数据单元。这些可任选的数据单元被指定为“非必要数据单元”。这些非必要数据单元的服务所要求的带宽可以被计算如下。例如，在嵌入编码的情况下，媒体数据包将持续T秒。假设媒体数据包被分成多个数据单元，那么，为了将层i处的数据单元供应给客户机，也必须将层i以下的所有数据单元供应给客户机。结果，供应层i处的数据单元所要求的服务带宽是Ri＝(i+1)L/T 公式1所以，公式1提供当考虑到嵌入编码媒体时数据单元的比特率R。然后，通过丢弃可能会导致可用服务带宽超过的比特率的非必要数据单元，PeerStreamer客户机可调整成更改服务带宽。
在任何情况下，无论媒体被非嵌入编码还是被嵌入编码，特定媒体流的所有数据单元，包括媒体数据包、媒体头部和媒体结构的据单元，都被映射到唯一的ID空间。例如，在一个测试实施例中，媒体数据包的数据单元从0x00000000到0xfdffffff(十六进制)索引，媒体头部的数据单元从0xfe000000-0xfeffffff编入索引，媒体结构的数据单元从0xff000000-0xffffffff编入索引。这个测试实施例中所使用的数据单元是关于图5中所示的PeerStreamer。
注意，为了获得媒体头部和媒体结构的数据单元ID，首先需要媒体头部和媒体结构的长度。这些被称作它们的“兆结构(mega-structure)”。为了获得媒体数据包的数据单元ID，需要媒体数据包比特流的长度。该信息被包括在媒体结构中。
3.1.4媒体的局部高速缓存出于服务目的，每个服务对等体只需要保持与其服务带宽成比例的媒体的一部分。与因特网连接的大多数计算机的服务(或上传带宽)常常实质上小于其下载带宽(规定每个特定节点可以接收的最高流传送比特率)。因此，因特网上的每个最终用户节点往往在其上传带宽与其下载带宽之间具有不平衡。例如，给定家庭用户可以获得的典型商业ADSL/电缆调制解调器网络上的节点，那么，下载带宽比其上传带宽高一个数量级并非是不平常的。同样，校园/企业网上的节点通常已改进了服务带宽，以便任何给定节点参与P2P类型活动都不会影响其它任务关键功能。
因此，由于每个服务对等体通常不能够个别地将全部媒体流供应给客户机，因此，不需要将全部媒体流高速缓存在任何一个服务对等体上。所以，用于减少服务对等体中的任一个所要求的存储资源数量的有效方法是允许每个服务对等体只保持将要被流传送的媒体的一部分。例如，如果流传送非嵌入编码媒体所需要的比特率是R，并且，流传送会话中的对等体所提供的最大服务带宽是B，那么，每个对等体节点只需要在其高速缓存中保持该流媒体的p部分，其中的值p由公式2来表示p＝max(1.0，B/R) 公式2例如，假设媒体比特率是服务带宽的两倍，即，R＝2B。然后，服务对等体只需要在其存储器中保持该流媒体的一半，因为该对等体无法独自按完全的流传送比特率来服务于客户机。实际上，给定这个例子的前述限制，该对等体所能够做得最好的是至多提供该媒体的一半。因此，该对等体只需要在其高速缓存中保持该媒体的一半。然后，将要被流传送的媒体的其余部分必须由其它服务对等体来提供。
另外，然后应该注意，公式1和2的组合随后允许确定为使用嵌入编码媒体的情况而保持的媒体量。如以上章节3.1.3中所讨论的，嵌入编码媒体的媒体数据包被分成具有不同的比特率的多个数据单元。所以，R是特定层L的数据单元的比特率，公式2现在给出将要为该数据单元而保持的媒体的部分。例如，如图6所示，嵌入媒体数据包可以被分成多个数据单元(在这个例子中是8个)。如图6所示，需要为每个数据单元(具有L/T＝0.5B)高速缓存的媒体量被示出为然后根据公式2来确定。
但是，在一个实施例中，在特定服务对等体的存储资源足够大的情况下，该服务对等体可以通过仅仅使用公式2中的较高的“潜在服务带宽”B′，来选择高速缓存该媒体的一个较大的部分。然后，被高速缓存的媒体的该额外部分允许按不连贯的、但高质量的方式来供应该媒体。例如，假设每个服务对等体选择使用其实际服务带宽两倍的潜在服务带宽B′(即，B′＝2B)，那么，该P2P网络中的所得的媒体量将足够客户机按流传送速率的一半来检索该媒体。换言之，假设所有这些可用对等体的合计服务带宽大于R/2，那么，客户机应该能够首先下载该媒体的一半，然后连续不断地流传送剩余的一半传送并对其进行回放。同样，客户机也可以选择下载该媒体的Ts/2片段(具有时间Ts)、连续不断地流传送另一个Ts/2片段并回放该片段、然后下载另一个片段并流传送它。这样，该流媒体可以按速率R来回放(纵使按不连贯的方式)。
3.1.5媒体的高速率擦除编码如上所述，对等体可能本质上是不可靠的。因此，有利的是提供用于在PeerStreamer系统和方法中提供增加的冗余度的某个手段，以便有效地处理服务对等体的本质上不可靠的服务行为。对这个问题的处理提出了必须解决的许多关注问题。例如，确定该媒体的哪个部分p应该由每个对等体来保持是所关注的。另外，由于媒体最终被分成前述数据单元，因此，确定每个对等体应该保持这些数据单元的哪个部分p也是所关注的。
解涣这些问颢的一个簧略星仅仅将每个数据单元分成k个块。保持该媒体的p部分的对等体随后可以随机地保持 个块， 是前述天棚函数。但是，对于这个方案的随机性的一个问题是即使对等体群集中存在比k个块多得多的块，该群集作为一个整体也可能会缺乏特定的块j，从而致使整个数据单元无法恢复。另外，在这种方案中，客户机仍然负责定位来自这些对等体的每个截然不同的块，这使客户机与对等体之间的协议设计复杂化。
因此，更好的策略是，使用“高速率擦除弹性代码”来确保对等体中的一个或多个将具有重建特定的数据单元所必要的数据块，同时简化客户机上识别对等体中的哪个对等体包含该必要数据的要求。一般而言，擦除弹性代码是具有参数(n，k)的块纠错码，其中，k是原始消息的数目，n是编码消的息的数目。高速率擦除弹性代码满足n比k大得多的属性；这样，k个原始消息被扩大为n个消息的大得多的编码消息空间。尽管擦除编码技术一般被公认为用于为数据编码，但如这里所描述的，该技术在P2P网络环境中流传送媒体的应用是未知的。
作为分组纠错码，可以通过伽罗瓦域(Galois Field)GF(p)上的矩阵乘法来描述高速率擦除弹性代码的操作c0c1······cn-1=Gx0x1···xk-1,]]>公式3其中，p是伽罗瓦域的阶，{x0，x1，…，xk-1}是原始消息，{c0，c1，…，cn-1}是编码的消息，G是生成矩阵。注意，公式3不用来立即生成所有编码的消息。而是生成矩阵G定义已编码消息空间。所以，当客户机接收k个编码的消息{c′0，c′1，…，c′k-1}时，它们可以被公式4表示为c′0c′1···c′k-1=Gkx0x1···xk-1,]]>公式4其中，Gk是对应于已编码消息的、生成矩阵G的k行所形成的子生成矩阵。另外，如果子生成矩阵Gk具有满秩k，那么，矩阵Gk可以被求逆，从而可以为原始消息解码。
可以使用几种众所周知的擦除编码技术，包括(例如)Reed-Solomon擦除码、tornado码和LPDC码。但是，在一个实施例中，PeerStreamer基于伽罗瓦域GF(216)上的修改Reed-Solomon码来提供一种新的高速率擦除弹性代码。在这个例子中，原始消息的数目k是16。已编码消息空间的大小n是216＝65536。Reed-Solomon码是最大距离可分(MDS)码。因此，生成矩阵G的任何16行形成具有满秩16的子生成矩阵。换言之，可以从任何16个已编码消息中恢复原始消息。应该注意，也可以使用其它域大小p；并且，PeerStreamer不局限于这里所描述的特定域大小的运用。另外，对于使用非MDS擦除编码的实施例，取决于所使用的特定擦除编码，可能有必要检索k′≥k个块，以恢复原始消息。使用基于Reed-Solomon的擦除代码部分是因为它们是MDS码，并且，它们可以被有效地编码和解码，同时，只将很少的计算额外开销施加于大多数常规计算机的CPU上。
利用高速率(n，k)擦除弹性代码，为每个对等体节点分配n的已编码消息空间中的k个关键字，每个关键字是生成矩阵G的行索引。关键字分配可以由服务器来执行。另外，如果高速缓存该媒体的对等体的数目小于n/k，那么，可以为每个对等体分配一组唯一的关键字。结果，可以保证每个对等体保持与众不同的已编码消息。这个策略提供许多好处，但它仍然要求中心协调节点(例如，服务器)。
因此，在另一个实施例中，通过允许每个对等体选择k个随机关键字，来消除中心协调节点的这个角色。如果对等体节点的数目大于n/k，或者没有利用中心协调节点来分配关键字，那么，某些对等体节点可以保持相同的关键字。然而，在其中客户机被连接到m个对等体的大多数媒体流传送会话中，m通常比n/k小得多。所以，两个服务对等体碰巧保持相同的关键字，并且因此这些对等体之一的一个关键字无用的概率很小。但是，即使有关键字冲突，当客户机首先连接到对等体时，它也可以容易地识别这类冲突。在识别这种冲突的情况下，该客户机仅仅在流传送会话的剩余部分内使这些重复的关键字中的一个无效。因此，客户机不需要实际上在流过程期间处理关键字冲突。
例如，假设S1和S2分别是服务对等体1和服务对等体2的擦除编码关键字空间，并且S1＝{1，7，23，43，48)，S2＝{3，7，28，49，99)。显而易见，关键字空间S1和S2是不同的。但是，关键字7由这两个关键字空间来共享，所以，服务对等体1和服务对等体2可以保持共享同一关键字(即关键字“7”)的擦除编码块。所以，在请求特定编码块之前，根据服务对等体之一来使关键字“7”无效，以便只从这些对等体之一中检索由关键字“7”编码的那个块，从而避免由重复关键字引起的任何解码冲突。但是，应该注意，在一个服务对等体在媒体流传送操作期间脱机的情况下，如果作为使用一个或多个重复关键字的结果该脱机服务对等体以前处于冲突状态，那么，可以使另一个服务对等体的特定的已无效编码关键字重新生效。
利用(65536，16)Reed-Solomon码，每个数据单元被分割成16个块。通过使用一组预先分配的关键字，该对等体选择高速缓存 个擦除编码块，其中，p是从公式1和2中计算的参数。被分配给该对等体的关键字、以及其最大服务带宽B组成该对等体的前述可用性向量，因为客户机可以通过使用该对等体可用性向量所提供的信息来确定该对等体保持多少和什么擦除编码块(按数据单元/块ID)。再一次，在最初连接每个对等体的时候，客户机解决任何关键字冲突。在流传送会话期间，客户机随后可以从任何服务对等体节点中检索任何k个已编码消息，并对相关联的数据单元进行解码。
另外，没有必要将用于为特定数据单元解码的编码块的整个集合存储在任何一个服务对等体上。换言之，对于任何特定数据单元的任何特定服务对等体所保持的块的数目可能小于k。所以，在一个实施例中，只生成实际上正被传递到特定对等体的那些编码块，而不是浪费计算能力来计算每个编码关键字的每个已编码块。换言之，如果j＜k个块被存储在特定的服务对等体上，那么，只应该为特定数据单元生成j个块。
3.2P2P网络中的PeerStreamer操作的实现在以下各段中，鉴于前面对PeerStreamer的操作细节的讨论，来描述PeerStreamer操作的实现。具体地，以下各段描述客户机对服务对等体的定位；基于所检索的媒体结构的客户机解码和呈现的设置；PeerStreamer网络连接；流传送比特率控制；PeerStreamer客户机请求和对等体答复；以及，最后是PeerStreamer请求和分级队列。
3.2.1定位服务对等体如上所述，客户机所执行的第一项任务是获得保持服务媒体的完整或部分副本的相邻服务对等体的列表的IP地址以及监听端口。另外，该列表也在媒体流传送会话期间被更新。如以上所解释的，用于获得该列表的一般方法包括1)从服务器中检索该列表；2)从已知的服务对等体中检索该列表；以及3)在预先既不知道媒体服务器，也不知道服务对等体的情况下，使用用于识别服务对等体的分布式散列表(DHT)方法。
3.2.2解码和呈现设置在获得服务对等体列表之后，客户机试图连接到这些服务对等体中的每一个。如上所述，一旦被连接，客户机就检索每个对等体的可用性向量，并解决任何关键字冲突。然后该客户机从这些对等体之一中检索媒体头部和媒体结构的长度。在检索了这两个长度之后，构造媒体头部和媒体结构的数据单元的ID。然后，按如章节3.2.6中进一步详细描述的P2P方式来检索媒体头部和媒体结构。一旦检索了媒体头部，客户机就确定应该对哪些解码器和呈现器进行初始化，以便在将媒体流传送到客户机时对它进行解码和呈现。
在使用DirectXTM来实现的一个测试实施例中，该设置通过首先根据媒体头部中所提供的信息来构造DirectShowTM过滤器图来实现。应该注意，这里所描述的PeerStreamer不局限于使用DirectXTM功能的实现，并且，只出于解释的目的来提供DirectXTM的运用及其相对于测试实施例的讨论，用于描述在为客户机回放而解码和呈现流媒体的过程中客户机计算机的设置。
所以，假设客户机设置的DirectXTM实现，客户机的网络组件由DirectShowTM网络源过滤器来表示，其输出被馈入正确的音频/视频解码器DirectXTM媒体对象(DMO)。然后，该DMO被进一步连接到适当的音频/视频呈现设备。例如，图7示出了客户机PeerStreamer媒体流传送会话的示例DirectShowTM过滤器图。在这个例子中，流媒体被非嵌入编码。音频比特流按WMA压缩，视频比特流按MPEG-4压缩。
经由DirectShowTM框架来使用和执行PeerStreamer客户机设置的一个优点是，它可以使用在DirectShowTM之下开发的巨大的现有音频/视频编码器/解码器库。例如，利用DirectShowTM，PeerStreamer客户机能够解码和呈现由各种编解码器(包括例如MPEG 1/2/4、WMA/WMV、Indeo Video等)或具有DirectShowTM解码器DMO组件的任何其它编解码器来编码的媒体。DirectShowTM也提供附加的音频/视频处理模块，例如，分辨率/色彩空间转换和解除交错，以便所解码的音频/视频可以自动与客户机的音频/视频呈现设备的性能相匹配。
另外，DirectShowTM自动处理音频/视频轨道的同步。例如，在音频流保持全部流的参考时钟的情况下，当播放流视频时，DirectShowTM确保该视频流的系统定时时钟尽可能接近于用于解决诸如嘴唇同步等问题的音频流时钟。最后，DirectShow应用程序本质上是多线程的。因此，在多处理器PC(或启用了超线程的PC)上，客户机的各个组件(例如，网络组件、音频解码器、视频解码器和音频/视频呈现引擎等)的计算负载可以被分发到多个处理器上。这大大加速了客户机的执行，并允许使用更复杂的音频/视频解码器。
最后，也应该注意，这里所描述的PeerStreamer不局限于使用DirectXTM功能的实现；并且，出于解释的目的，提供了DirectXTM的运用及其相对于测试实施例的讨论，只用于描述在为客户机回放而解码和呈现流媒体的过程中客户机计算机的设置。
3.2.3PeerStreamer网络链路和数据包丢失管理大多数媒体流客户机，例如，Windows媒体播放器或RealPlayer，使用在UDP之上所携带的公知的实时传送协议(RTP)。通常为媒体流应用程序选择UDP/RTP，这是因为1)UDP协议支持IP多点传送，它在将媒体发送到启用了IP多点传送的网络上的一组节点的过程中会是有效率的；以及2)UDP协议不具有任何重发或数据速率管理功能。因此，流传送服务器和客户机可以实现诸如前向纠错(FEC)等高级数据包传递功能，以确保媒体数据包的及时传递。
但是，与以上所标识的公知的媒体流传送方案对比而言，PeerStreamer将TCP连接用作客户机与服务对等体之间的网络链路。选择TCP连接而不是常规的UDP/RTP协议的一个原因是，由于诸如域内路由协议、ISP商业模型(收费模型)、沿分布树的拥塞控制等问题，在现实世界中，没有广泛地采用IP多点传送。
此外，与许多商业媒体播放器一样，PeerStreamer客户机并入流媒体缓冲区(在测试实施例中是4s)，以防止诸如抖动和拥塞等网络异常。实际上，给定比客户机与服务对等体之间的往返时间(RTT)大许多倍的流媒体缓冲区，那么，TCP ARQ(自动化重复请求)机制对于媒体数据包在充分的时间内的传递而言足够好，以便提供流媒体的流畅的回放。
一般而言，有三种公知的机制(具有大量公知的变体)用于解决媒体数据包丢失。例如，这些机制通常包括FEC、选择性数据包重发、以及自动重复请求(ARQ)。PeerStreamer可以使用所有这些数据包丢失机制中的任一种。但是，如以下所解释的，使用特定的机制有胜过其它机制的各种优点。
具体地，对于可以被认为是具有变化的特征和未知的数据包丢失率的擦除通道的因特网信道，固定的FEC方案要么浪费带宽(具有太多的保护)，要么无法恢复丢失的数据包(具有太少的保护)。这样，它未能有效地利用客户机与对等体之间的带宽资源。所以，利用比RTT大许多倍的流传送缓冲区、以及因而关于重发的许多机会，基于重发的出错防止(例如，选择性重发和ARQ)比FEC更可取。
考虑到ARQ和选择性重发，可见到，在使用TCP协议的因特网信道中，只有当许多数据包没有被选择来重发的时候，选择性重发将比ARQ强。对于非嵌入编码媒体，丢失的数据包通常会导致严重的回放降级，包括无法解码和提供特定数据包的回放。所以，丢失的数据包几乎总是被重发。相反，利用嵌入编码媒体，丢失的数据包可能不会妨碍媒体回放。但是，随机数据包的丢失仍然会使许多导出的数据包变得不可用。结果，只有最高增强层数据包可能不会被选择来重发。
与选择性重发相比较，一旦请求数据包，ARQ总是重发它们；即使它们属于最高增强层。然而，ARQ方案可以选择不请求随后媒体数据包的最高增强层数据包，从而利用选择性传输方案来实现相同的带宽使用率和察觉到的媒体回放质量。因此，除非网络条件变化非常迅速，否则，TCP协议所使用的ARQ机制足以处理媒体流传送中的数据包丢失。
将TCP用作网络协议也可提供胜过诸如以上所标识的常规媒体流传送方案的几个额外的好处。例如，利用TCP，不需要明确地处理流量控制、吞吐量估算、拥塞控制和避免、保活(keep alive)等等。所有这些问题由TCP协议来自动处理。TCP协议也可以检测脱机的对等体，并适度地处理该对等体与客户机之间的连接链路的关闭。
3.2.4具有嵌入编码的PeerStreamer流传送比特率控制非嵌入编码的媒体较佳地总是按该媒体的比特率来流传送，以避免在客户机处的媒体回放降级。但是，嵌入编码媒体的流传送比特率可以在流传送会话期间变化。
所以，在一个实施例中，每个嵌入编码媒体数据包的流传送比特率Rrecv首先由公式5、6和7来计算，如下所示Rraw＝Th·(1+Trft-Tstaging)+Bstaging-Boutstanding公式5Rfilter＝(1-α)Rfilter+αRraw公式6Rrecv＝min(Rmin，Rinst) 公式7其中，Th是多个服务对等体的总计的服务带宽，Tstaging是目标分级缓冲区大小(在测试实施例中具有默认值2.5s)，Trft是所需的请求履行时间(在测试实施例中具有默认值1.0s)，Bstaging是分级队列中所接收的数据包的长度，Boutstanding是将要被接收的未完成答复的长度，Rmin是基层比特率(只具有必要数据单元)，α是低通控制参数。
然后，使用公式5-7的结果来通过以下总计的服务带宽Th、以及各个分级和请求队列状态而控制流传送比特率Rrecv，这些分级和请求队列状态在以下章节3.2.6中进一步详细描述。一旦确定该流传送比特率，客户机就只发出对具有低于流传送比特率Rrecv的比特率的数据单元的请求。
在一个相关实施例中，通过也考虑数据单元的失真作用，使用更高级的策略来控制比特率Rrecv。但是，这要求客户机获得对数据单元的失真(或码率失真斜率)的访问，它必须被包括在媒体结构中并被发送到客户机。但是，与媒体结构中的现有信息不同，数据单元的失真在解码的过程中是不需要的，因而被认为是额外开销。因此，它是将要被发送到客户机的额外开销量与速率控制准确度之间的折衷。
3.2.5PeerStreamer数据块请求和答复图8概括地示出了客户机数据块请求及其对对等体的答复的使用期限。具体地，如图8所示，客户机生成该请求，并通过出站TCP连接来将它发送到特定的服务对等体。另外，在网络传递中，TCP可以将该请求与发给同一对等体的原先的请求捆绑在一起。如果原先的请求在传输过程中丢失，那么，TCP也处理该请求的重发。
在数据包请求被传递到对等体之后，它被存储在该服务对等体的TCP接收缓冲区中。然后，该对等体处理这些请求，每次处理一个请求。对于每个请求，对等体从其磁盘或记忆存储中读取所请求的块(可能被或可能不被擦除编码，取决于所使用的编码)，并将所请求的内容发回到客户机。倘若从服务对等体到客户机的TCP套接字被阻断(即，不再有带宽可用)，那么，服务对等体将阻断进一步的客户机请求，直到TCP连接打开为止。
客户机发出请求的时间与客户机接收其答复的时间之间的间隔被定义为请求履行时间(RFT)。请求通常比其答复小得多，并且，与用来发回内容的网络传递时间相比，处理请求的过程中所涉及的操作(例如，磁盘读取)通常是不重要的。所以，请求的RFT-Trft由公式8来计算，如下所示Trft′＝(Bi，outstanding+Bcur)/Thi公式8其中，Thi是对等体i的服务带宽，Bi，outstanding是在该请求之前的未被接收的答复的长度，Bcur是所请求的内容的长度。所以，RFT是根据对等体的服务带宽、请求的大小、以及来自该对等体的未被接收的内容的大小来确定的。
一旦所请求的内容数据包到达客户机处，它就被立即移动到分级队列。在该分级队列中，来自多个对等体的数据块(可以包括擦除编码块)被组合和解码为数据单元，这些数据单元被进一步组合成媒体数据包。客户机周期性地从分级队列中除去所传递的媒体数据包，并将它们压入对应的音频/视频解码器。在媒体数据包被解码器解压之后，未压缩的音频/视频数据流被发送到音频/视频呈现单元，用于客户机回放设备(监视器、扬声器等)上的流回放。
在一个实施例中，图8中所示的缓冲区用来防止网络异常(例如，数据包丢失和抖动)。
(但是，当使用DirectShowTM实现时，未压缩的音频/视频缓冲区在DirectShow过滤器图的控制之下，并且是不可编程的。)在PeerStreamer的一个测试实施例中，分级缓冲区的大小被设为Tstaging＝2.5s，所需的RFT被设为Trft＝1.0s，并且，所压缩的音频/视频缓冲区被设为0.5s。因此，在这个测试实施例中，PeerStreamer客户机的总缓冲区因而大约是4s。
在其中使用擦除编码的实施例中，每个数据块请求被明确地表达为某个数据单元的一组擦除编码块的请求。可以利用起始块索引和所请求的块的数量来标识该擦除编码块组。可以通过32位ID来标识该数据单元。该请求因而采取以下形式Data_Unit_ID[32]，Start_Index[4]，Number_of_Blocks[4]公式9其中，括号中的数字是每个分量的比特数。
所以，如公式9所示，在擦除编码块的情况下，每个请求是5字节长。另一方面，所请求的内容在大小方面的范围是128～2048个字节(数据单元长度L＝2048，k＝16)。结果，请求的大小只是答复的大约0.24％～3.91％。所以，客户机用于发送请求的上传带宽的量相对于请求的内容而言非常小。
3.2.6PeerStreamer请求和分级队列如上所述，PeerStreamer客户机维持单个分级队列，以保持所接收的数据块(可以被擦除编码)；并且，从其中，数据块被组装成数据单元，然后被组装成媒体数据包。客户机也保持用于服务对等体中的每一个的单独的请求队列，以保持被发送到每个对等体的无法履行的请求。图9示出了请求队列和分级队列的一个例子。
分级队列是PeerStreamer客户机的主要流缓冲区。所有接收到的内容首先被放入该分级队列。这些请求队列用于三个目的1)用于执行吞吐量控制和负载平衡；2)用于识别由每个服务对等体发回的答复；以及3)用于处理断开的对等体。
请求队列的第一个功能是平衡服务对等体之中的负载。在媒体被擦除编码的情况下，对数据单元的请求被分成多个擦除编码块组的请求，每个组被定向到一个对等体。通过以下操作来生成这些请求。一当请求数据单元，客户机就首先检验对等体的可用性向量，并对该数据单元计算每个对等体所保持的擦除编码块的数量(ai)。如果所有联机对等体所保持的块的总数小于k，那么，该数据单元不可检索。如果不可检索的数据单元是非必要的(即嵌入编码媒体的非基层)，那么，客户机只需跳过该数据单元。
相反，如果不可检索的数据单元是必要的(即，属于非嵌入编码媒体数据包、或嵌入编码媒体数据包的基层)，那么，客户机无法继续进行流媒体的下载和回放。所以，在一个实施例中，它将等待更多的对等体联机，以提供这些缺少的块。在一个替换实施例中，客户机将跳过整个媒体数据包，并向以后的音频/视频解码器将它标记为“缺少的”。其结果将是所呈现的媒体中的间隙或跳跃。但是，如果无法从对等体群集中重新获得一个必要的数据单元，那么，以后更多的必要数据单元将很可能也是不可检索的。因此，通常更好的做法是让客户机等待，直到数据可用为止，以便为用户提供更好的回放体验。
在确保特定数据单元是可重新检索的之后，即，Σiai≥k 公式10客户机检验每个对等体的请求队列中的可用空间。需要将每个对等体的RFT保持在系统常数Trft左右。在一个测试实施例中，1.0s数量级的Trfr提供较好结果。(注意，使用太短的请求队列可能不会有效地利用从客户机到对等体的带宽。)具体地，如果客户机所发送的请求数据包被丢失或被延迟，那么，服务对等体可能没有什么东西要发送，这会浪费其服务带宽。相反，使用过长的请求队列可以防止客户机迅速适应变化，例如，对等体之一的断开。另外，如果请求队列对于所有的对等体在RFT方面都是相同的长度，该请求队列的容量变得与其服务带宽Thi·Trft成比例。
例如，假设Trft是1.0s，那么，具有服务带宽16kbps的对等体允许其请求队列中有2KB的无法履行的请求待决，而具有服务带宽1Mbps的对等体允许128KB的无法履行的请求待决。因此，可以向特定对等体请求的擦除编码块的数量由其请求队列中留出的空间来定上限ei＝min(ai，(Thi·Trft-Bi，outstanding)/bk) 公式11其中，ei是可以向对等体i请求的擦除编码块的数量，bk是擦除编码块的大小。
公式11保证客户机从不发出具有大于Trft的预期的RFT的请求。如果客户机无法找到足够的当前可用的擦除编码块，即，∑iei＜k 公式12它将等待，直到服务对等体的请求队列清除为止。当∑iei≥k时，数据单元请求只是被形成并被发送到对等体。向某个对等体请求的块的实际数目(bi)被计算如下Σibi=k,bi=min(ei,c·Thi),]]>公式13其中，c是满足∑ibi＝k的常数。
一般而言，以上略述的过程与其服务带宽Thi成比例地将服务负载分配给每个对等体(公式13)。它也确保客户机不会向特定服务对等体请求比该服务对等体实际上所高速缓存或存储的更多的块。最后，如公式11所示的，该过程也确保请求的RFT不超过Trft。
请求队列的第二个功能是识别由每个服务对等体发回的内容。如上所述，PeerStreamer客户机和对等体通过TCP来进行通信，它保存数据传输的顺序，并保证数据包传递。而且，每个对等体依次处理传入的请求。结果，不需要明确地识别被发回的内容，因为它必须赞成每个对等体的请求队列中待决的第一个请求。
对于上述的请求队列的第三个功能，该请求队列也用来使断开的对等体的各个请求重定向。例如，只要特定的服务对等体与客户机断开，该断开事件都由TCP协议来获得，TCP协议随后将该断开报告给客户机。然后，客户机将断开的对等体的队列中待决的所有无法履行的请求再分配给剩余的对等体中的一个或多个。用于再分配请求的过程十分类似于用于分配第一个地方的请求的过程。唯一的例外是，在请求再分配时，必须考虑已经向断开的对等体请求的块的数目。
最后，只要擦除编码块到达客户机处，它们都立即离开TCP套接字。在将到达的内容与待决的请求配对之后，从请求队列中除去已履行的请求。然后，所识别的擦除编码块被放入分级队列。结果，分级队列的大小增加。如果分级队列达到预定大小Tstaging，那么，不发送媒体数据包/数据单元的更多请求。一旦已接收某个数据单元的所有擦除编码块，该数据单元就被擦除解码，并被标记为“就绪”。如果所有其所请求的数据单元就绪，那么，媒体数据包变成就绪。音频/视频解码器周期性地从分级队列中除去“就绪”的媒体数据包。这减小分级队列的大小，并可能会触发新媒体数据包请求的生成。
以上所述的媒体流传送操作随后继续进行，直到完成媒体文件的回放，或直到诸如没有足够的对等体可用来流传送媒体等时刻，或用户终止流传送会话。
3.3PeerStreamer操作以上根据图2至图9描述的过程由图10中的通用操作流程图来示出。一般而言，图10展示了示出PeerStreamer的几个操作实施例的示例性操作流程图。应该注意，由图10中的虚线来表示的任何方框和方框之间的互连表示这里所描述的PeerStreamer的替换实施例；并且，如下所述，可以结合在整个文档中描述的其它替换实施例来使用任何或所有这些替换实施例。
具体地，如图10所示，在媒体流传送操作之前，服务器200(也可能是对等体220之一)对将要流传送的媒体进行编码(1000)。如上所述，PeerStreamer能够利用许多常规编解码器(例如，MPEG 1/2/4、WMA、WMV等)中的任何一种来进行操作。此外，在编码过程1000期间，服务器200也生成前述的媒体头部和包含媒体结构的伴随文件。
如上所述，在一个实施例中，一旦媒体被编码(1000)，所编码的媒体数据包就被分成(1005)多个固定大小的数据单元。另外，对于所编码的媒体，媒体头部和媒体结构也被分成(1005)多个与用来分割已编码媒体数据包的相同的固定大小的数据单元。如以上所解释的，通过将信息分成(1005)固定长度数据单元，来允许客户机和服务对等体在媒体流传送操作之前预先分配存储块，从而在流传送过程期间避免计算上昂贵的存储器分配操作。另外，较小的数据单元的运用允许客户机对每个服务对等体所消耗的确切的带宽数量的较精细的控制，以便在流传送操作期间满足客户机数据单元请求。
除了将已编码媒体、媒体头部和媒体结构分成(1005)较小的数据单元以外，在一个实施例中，附加编码层还用来在服务对等体本质上不可靠的典型P2P环境中提供增加的冗余度。具体地，如上所述，在一个实施例中，使用基于关键字的高速率擦除弹性编码过程1010，来将这些数据单元进一步分成多个数据块。
这类编码1010的运用确保对等体中的一个或多个将具有重建特定的数据单元所必要数据块，同时，简化客户机上识别对等体中的哪一个包含必要数据的要求。另外，如上所述，在一个实施例中，每个服务对等体220所使用的擦除弹性编码关键字被服务器200自动分配给每个对等体。但是，在另一个实施例中，每个服务对等体220仅仅随机地选择擦除弹性编码关键字。然后，当每个对等体220最初由客户机来联系时，这些关键字连同前述的可用性向量一起被包括在内对等体客户机，可用性向量由客户机210来检索。在随机关键字实施例中，在对给定数据单元存在关键字冲突的情况下，客户机随后使一个或多个对等体的关键字无效。
一旦媒体最初已被编码(1000)、被分成数据单元(1005)并可能进一步被擦除编码(1010)，最后得到的数据单元或数据块随后就被分发(1015)给各个服务对等体220。该分发(1015)会是深思熟虑的，这体现在已编码媒体的块或数据包仅仅被全部或部分地提供给多个对等体，它随后被高速缓存或存储在那里，用于当被与P2P网络连接的客户机调用时的进一步的流传送操作。
或者，如上所述，只要客户机210流传送特定的媒体文件，恢复的媒体数据包都只是编码操作1000之后的媒体数据包。它们可以被分成数据单元(1005)，并可被进一步擦除编码(1010)；并且，客户机可能在本地存储器或存储单元内维持流传送到它那里的内容的至少一部分。然后，客户机被识别为服务对等体220(在前述对等体列表310中)，用于将来的流传送操作。这个实施例的一个优点是包含特定媒体文件的各个部分的对等体的数目最初很低，从而增加对服务器本身的要求，以满足服务请求，但随着时间的流逝并且更多客户机流传送该媒体，那些客户机随后将能够担当用于以后的流传送请求的对等体。因此，不需要明确地选择服务对等体220，以保持将要被流传送的媒体的全部或一部分的初始高速缓存。结果，对于试图识别愿意接受将要被流传送的媒体的初始高速缓存的对等体，进一步减少服务器上的任何要求。
在任何情况下，一旦媒体已被分发(1015)给服务对等体220，客户机210随后就准备好开始将请求流传送到那些服务对等体。另外，如上所述，出于流传送到客户机210的目的，服务器200也可以担当服务对等体220。再有，鉴于以上讨论，应该清楚，随着时间的流逝，特定媒体文件的初始流传送可以要求更大的服务器200牵涉，并且，更多客户机210流传送该媒体(并且随后可用于担当服务对等体)，对对等体服务器的实际上担当服务对等体的各个要求被减少或甚至被消除。
这时，客户机210通过首先检索可用服务对等体220的列表310，来开始流传送会话。如上所述，该列表310直接从服务器200中、从对等体220之一中、或通过使用用于识别潜在服务对等体的常规DHT方法315来检索。一旦客户机210检索了对等体列表310，该客户机随后就连接到每个服务对等体220，并从每个对等体中检索(1025)可用性向量。另外，在一个实施例中，客户机210在正在进行的流传送操作期间周期性核对对于对等体列表310的更新(1030)。执行这类周期性核对(1030)的一个优点是在大型P2P网络中，多个服务对等体任何给定的时刻正在联机和脱机是可能的。因此，确保客户机210具有已更新的对等体列表310将允许该客户机响应于当前正将媒体流传送到该客户机的对等体220的丢失或降级。只要列表310的周期性核对(1030)指出对该列表添加新的对等体220，客户机210就再次连接到该新的对等体，并检索(1025)该新的对等体的可用性向量。
一旦客户机210检索(1025)了每个对等体220的可用性向量，该客户机随后就通过经由该客户机与那些对等体之间的网络连接而请求对应于来自这些对等体中的一个或多个的信息的数据单元，来检索(1035)将要从这些服务对等体中的一个或多个流传送的媒体的媒体头部和媒体结构。
如上所述，媒体头部通常包含描述该媒体的全局信息，例如，媒体中的通道数目、每个通道的属性和特征(音频采样率、视频分辨率/帧速率)、所使用的编解码器、媒体的作者/版权持有者、等等。因此，媒体流传送会话的起始处的媒体头部的检索允许客户机220对这些必要的工具进行设置或初始化(1040)，以便在该流传送会话期间接收那些数据包之前对随后接收的数据包进行解码(1070)和呈现(1075)。
另外，在检索(1035)特定流媒体的媒体结构之后，客户机分析该媒体结构，并计算在流传送过程期间将需要被请求的流媒体的数据单元的数据单元ID(1045)。然后，客户机210向服务对等体220中的一个或多个逐个地请求那些数据单元(1050)。
另外，如上所述，在结合编码关键字的随机对等体选择来使用擦除编码的实施例中，客户机210将使对等体一个或多个对等体220上的重复关键字无效，以便管理关键字冲突(1055)。在一个相关实施例中，PeerStreamer使用嵌入编码媒体，并且，随后根据可用的服务带宽和客户机210队列状态来管理(1060)每个对等体220的数据请求(和流传送比特率)。在此情况下，数据单元的正在进行的请求(1050)对应于将基于各个服务对等体的可用带宽来提供最小码率失真的那些数据包。在任何情况下，如上所述，根据已使用嵌入还是非嵌入编码、对等体的连接状态、以及剩下来用于请求和接收缺少的或后来的数据单元的时间，来再次向同一或另一对等体220请求(1050)缺少的或后来的数据单元。
最后，一旦根据客户机220请求(1050)检索了构成特定媒体数据包的所有数据单元，那些数据包就被重新组装(1065)成原始媒体数据包。然后，重新组装的媒体数据包被解码(1070)、被呈现(1075)和被提供，用于常规的显示设备355或扬声器260中的任何一个或两者上的回放。
已出于举例说明和描述的目的来呈现对PeerStreamer的前述描述。它并不意在做到详尽或将本发明局限于所揭示的精确形式。按照以上的教导，许多修改和变更是可能的。另外，应该注意，可以在形成PeerStreamer的其它混合式实施例所需要的任何组合中使用任何或所有这些上述的替换实施例。本发明的范围意在不受到本详细描述的限制，而是受到所附权利要求书的限制。
权利要求
1.一种具有计算机可执行指令的计算机可读介质，所述指令用于提供对等(P2P)网络中多媒体数据包的客户机驱动流传送，所述计算机可执行指令包括在客户机计算机上维护多个客户机请求队列，每个客户机请求队列对应于服务对等体群集中的多个服务对等体之一；将一个或多个数据包的客户机请求发送给多个服务对等体；当每一数据包请求从所述客户机发送到所述服务对等体之一时，将所述每一数据包请求添加到所述对应的请求队列；当所述对应的数据包由所述客户机从所述服务对等体接收时，从所述对应的请求队列中移除每个数据包请求；将每个接收到的数据包提供给由所述客户机维护的公用分级队列；以及将所述公用分级队列中的数据包组装成对应的多媒体数据包。
2.如权利要求1所述的计算机可读介质，其特征在于，在客户机计算机上维护多个客户机请求队列还包括创建和维护对应于加入所述服务对等体群集的任一服务对等体的的附加客户机请求队列。
3.如权利要求1所述的计算机可读介质，其特征在于，在客户机计算机上维护多个客户机请求队列还包括将遗留在对应于从所述服务对等体群集中丢弃的服务对等体的请求队列中的任何数据包请求移动到一个或多个其它客户机请求队列。
4.如权利要求1所述的计算机可读介质，其特征在于，负载平衡是通过提供对跨越所述服务对等体群集中的每个服务对等体维护近似一致的请求履行时间(RFT)的数据包请求的客户机管理，跨越所述服务对等体群集中的每个服务对等体维护的。
5.如权利要求1所述的计算机可读介质，其特征在于，对任一服务对等体的所述客户机数据包请求是通过到所述服务对等体的可靠且保持次序的链接来提供的，使得所述服务对等体不必标识在对所述客户机请求的回复中发送的数据包。
6.如权利要求5所述的计算机可读介质，其特征在于，到所述服务对等体的可靠且保持次序的链接是TCP通信协议。
7.如权利要求5所述的计算机可读介质，其特征在于，由所述客户机从服务对等体接收的任一传入数据包与对应于从从其中接收所述数据包的服务对等体的请求队列中的第一个数据包请求相对应于。
8.如权利要求1所述的计算机可读介质，其特征在于，对特定服务对等体的特定数据包的客户机请求是基于从每个所述服务对等体检索的可用性向量的客户机分析而做出的，并且其中，从每个服务对等体接收的所述可用性向量至少定义了存储在每个对应的服务对等体上的可用性数据包。
9.如权利要求1所述的计算机可读介质，其特征在于，还包括在所述客户机计算机上解码和呈现所组装的多媒体数据包，以在所述客户机计算机上提供流媒体回放。
10.如权利要求1所述的计算机可读介质，其特征在于，所述数据包是嵌入编码的数据包。
11.如权利要求10所述的计算机可读介质，其特征在于，还包括根据下列，通过将一个或多个数据包的所述客户机请求自动限制到多个服务对等体，来维护对每个嵌入编码数据包的流传送比特率的客户机控制所述服务对等体的总计服务带宽；所述公用分级队列的大小；期望的请求履行时间；在所述公用分级队列中接收的数据包的长度；每个请求队列中的待决回复的长度；以及所述嵌入编码的数据包的基层比特率。
12.一种用于提供对等体(P2P)网络中的客户机控制的媒体文件流传送的方法，包括使用计算设备，以便在可用服务对等体群集中的一个或多个服务对等体上存储已编码的媒体文件的一个或多个数据包，所述已编码的媒体文件包括媒体头部和媒体主体，使得所述已编码的媒体文件的每一数据包高速缓存在至少一个所述服务对等体中；使用所述客户机以检索对所述客户机可用的服务对等体的列表；为每个可用的服务对等体初始化所述客户机上的单独的数据包请求队列；将对一个或多个特定数据包的一个或多个客户机请求发送到一个或多个特定服务对等体，以及将每个请求添加到对应的数据包请求队列；当所述对应的数据包由所述客户机接收时，从所述对应的数据包请求队列中移除每个请求；以及解码和呈现所接收的数据包，以在所述客户机上提供流媒体回放。
13.如权利要求12所述的方法，其特征在于，还包括将每个可用服务对等体的可用性向量下载到所述客户机，其中，每个可用性向量描述了存储在每个对应的服务对等体上的可用数据包，并且其中，对一个或多个特定数据包的客户机请求基于所下载的可用性向量。
14.如权利要求12所述的方法，其特征在于，解码和呈现所接收的数据包还包括在所述客户机上回放之前，至少部分地缓冲所解码和呈现的数据包。
15.如权利要求12所述的方法，其特征在于，为每个可用的服务对等体初始化所述客户机上的单独的数据包请求队列还包括创建和维护对应于加入所述服务对等体群集的任一服务对等体的附加客户机数据包请求队列。
16.如权利要求12所述的方法，其特征在于，还包括将遗留在对应于对所述客户机不可用的服务对等体的数据包请求队列中的任何数据包请求移到一个或多个其它数据包请求队列，以及向所述对应的服务对等体请求所述的数据包。
17.如权利要求12所述的方法，其特征在于，还包括通过提供对跨越每一所述可用服务对等体上维护期望的请求履行时间(RTF)的数据包请求的动态客户机管理，在每个所述可用服务对等体之间执行带宽负载平衡。
18.如权利要求12所述的方法，其特征在于，对任一服务对等体的所述客户机数据包请求是通过TCP通信协议提供的，，其中，所述服务对等体不标识在对每个特定客户机请求的回复中发送的数据包，并且其中，由所述客户机从服务对等体接收的任何传入数据包与对应于从其中接收所述数据包的服务对等体的请求队列中的第一个数据包请求相对应。
19.如权利要求12所述的方法，其特征在于，所述数据包是嵌入编码的数据包，并且其中，通过将对一个或多个特定数据包的客户机请求自动限制到一个或多个特定服务对等体，维护对每个嵌入编码数据包的流传送比特率的客户机控制。
20.如权利要求19所述的方法，其特征在于，根据下列自动限制所述客户机请求所述服务对等体的总计服务带宽；客户机分级缓冲区大小；期望的请求履行时间(RFT)；所述客户机分级缓冲区中接收到的数据包的长度每个数据包请求队列的长度；以及嵌入编码的数据包的基层比特率。
21.一种协调从一个或多个非协作对等体的群集的客户机驱动媒体流传送的系统，包括跨越可用于与客户机通信的服务对等体群集中的一个或多个服务对等体分发已编码的媒体文件的所有数据包；响应于客户机请求，将所述群集中的服务对等体的列表提供给所述客户机；提供对应于所述群集中的每个服务对等体的客户机上的单独的数据包请求队列；将对一个或多个特定数据包的一个或多个客户机请求发送给所述群集中一个或多个特定服务对等体，并且将每个请求添加到所述对应的数据包请求队列；当所述客户机接收到所述对应的数据包时，从所述对应的数据包请求队列中移除每个请求；在客户机分级队列中高速缓存每个所接收的数据包；以及解码和呈现所接收的数据包，以在所述客户机上提供流媒体回放。
22.如权利要求21所述的系统，其特征在于，还包括响应于客户机请求，提供所述群集中的每个服务对等体的可用性向量，并且其中，每个可用性向量描述了存储在每个对应的服务对等体上的可用数据包。
23.如权利要求22所述的系统，其特征在于，将对一个或多个特定数据包的一个或多个客户机请求发送给所述群集中的一个或多个特定服务对等体是基于对应于所述群集中的每个服务对等体的可用性向量的客户机分析。
24.如权利要求21所述的系统，其特征在于，所述客户机分级队列的长度是不同的，以在解码和呈现所接收的数据包之前提供所请求的数据包的期望数量的缓冲。
25.如权利要求21所述的系统，其特征在于，提供对应于所述群集中的每个服务对等体的客户机上的单独的数据包请求队列还包括响应于任何服务对等体加入和离开所述群集，分别动态地添加和移除客户机请求队列中的任一个。
26.如权利要求21所述的系统，其特征在于，响应于任何服务对等体离开所述群集移除客户机请求队列还包括将遗留在任何移除的客户机请求队列中的任何数据包请求移到一个或多个其它客户机请求队列，以及向所述对应的服务对等体请求所述对应的数据包。
27.如权利要求21所述的系统，其特征在于，还包括通过动态地平衡客户机数据包请求在所述群集中的每个服务对等体之间执行带宽负载平衡，以对所述群集中的每个服务对等体维护期望的请求履行时间(RFT)。
28.如权利要求21所述的系统，其特征在于，所述客户机数据包请求是通过TCP通信协议发送给各个服务对等体的，并且其中，由所述客户机从特定服务对等体接收的任何传入数据包对应于所述对应的客户机请求队列中的第一个数据包请求。
全文摘要
“PeerStreamer”提供用于松散耦合的P2P网络的接收器驱动对等(P2P)媒体流传送。该网络中的对等体只执行简单的操作、可以高速缓存流媒体的全部或一部分、不与其他对等体协作、可以是不可靠的、以及可以在任何给定的流传送会话期间脱机或联机。该网络中的客户机进行实时操作，以便协调对等体、从多个对等体流传送媒体、执行负载平衡、处理对等体的联机/脱机状态、以及执行对该流媒体的解码和呈现。在一个实施例中，PeerStreamer使用高速率擦除弹性编码来允许多个服务对等体保持部分媒体而无冲突，以便客户机仅仅检索固定数量的擦除编码块，而不管在哪里检索和检索什么特定块。在另一个实施例中，PeerStreamer使用嵌入编码媒体来根据可用的服务带宽和客户机队列状态而改变流传送比特率。
文档编号H04L29/02GK1758646SQ200510099119
公开日2006年4月12日 申请日期2005年8月31日 优先权日2004年9月3日
发明者李劲 申请人:微软公司