RTSP-based移动p2p流媒体系统

文摘

点对点正成为一个潜在的颠覆性技术在移动互联网内容分发。除了已经众所周知的对等文件共享,实时p2p流媒体是越来越受欢迎。介绍了一种有效的实时移动p2p流媒体系统环境。系统是一个可伸缩的覆盖网络的基础窥视集群组根据他们的同龄人之间的距离使用RTT值作为集群的标准选择。实际系统中媒体交付使用部分实现RTP流概念:最初的RTP会话相关媒体交付分成许多所谓的局部流根据一组预定义的参数以这样一种方式,它允许低重新组装的原始媒体实时会话在接收端。部分流也有助于利用细的粒度的上传能力不仅仅是每一个原始流。这是有益的在移动环境中,带宽是很稀缺的。

1。介绍

点对点(P2P)流媒体应用程序获得越来越多的世界各地的用户。这些应用程序允许用户实时广播内容整个互联网,而不需要任何特殊的基础设施,因为用户的设备,和其他同事一起,共同构成了基础设施。此外,专用服务器不再需要因为每个同行可以提供数据给其他同行。这与一个服务像YouTube [1)仍然需要上传到中央服务器的内容。目前现有的P2P流媒体应用程序,比如Octoshape [2]和SopCast [3),适合于在移动环境中使用,但仍有许多问题需要解决之前为移动设备优化的解决方案可以实现(4]。

实时P2P流媒体不需要下载整个媒体文件播放之前开始。解码可以尽快开始足够的数据缓冲的同行。这避免了启动时间长,并消除了需要存储整个内容在移动设备上仍有相对少量的内存大小的增加相比实际的媒体。在直播,视频的一个正在进行的事件,像一个足球比赛,作为一个实时流交付。最初的缓冲阶段后,用户开始看流从一个特定的位置和所有同行消费数据在同一时间窗口。视频点播(VoD)从一些目录,用户搜索一个视频流和一定数量的初始缓冲后用户从一开始就开始播放视频。

为了增加鲁棒性和适应有限,和下载带宽网络,同行之间最初的多媒体会话需要分成更小的部分,可以重新在接收同行到原始的媒体表示。提出了一种有效的实时P2P流媒体系统,原来的实时传输协议(RTP) [5)会话相关媒体交付分成许多所谓的局部流根据一组预定义的参数。这种方法允许低重新组装的原始媒体实时会话在接收端。

本文的其余部分的结构如下。讨论了相关工作2。然后,系统给出的简短概述部分3。详细描述的覆盖网络和媒体交付的部分4- - - - - -8。之后,从性能实验结果提出了部分9。有趣的领域进一步的工作进行了讨论和突出显示部分10。最后,部分11本文总结道。

许多P2P文件共享应用程序使用多个源分布。文件第一次分割成碎片或块,一般的大小。对等连接到播种机或吸血鬼同行,并请求丢失的部分文件在一个随机的顺序。播种机和吸血鬼同伴之间的区别是,前者有一个完整的文件副本,而后者只有部分复制。例如,使用bt (6)完整的多媒体文件可以划分为256 KB的块,然后选择感兴趣的同行和要求根据一块rarest-first选择算法。这种方法不适合流媒体应用程序,因为它没有考虑延迟的问题。用户可能会经历长时间下载的延误可能好几天。它还假设源的全部内容和可用同行,这并不一定适用于流媒体应用程序流可能生活。

P2P多媒体流媒体解决方案提出了基于bt协议(7]。rarest-first块下载政策是政策所取代,同行第一块下载将在不久的将来使用。针锋相对的同伴选择策略也修改为允许自由尝试更多的同行,让同龄人更早参与多媒体分布。另一个P2P流媒体系统提出了基于P2P文件共享的实现已经在8]。然而,基于固定字节的数据分区范围不适合连续媒体流,这是大自然的可变比特率。

在P2P内容分发,创建一个覆盖网络在应用程序层为了传输网络中节点之间的实际内容。随机基于网格覆盖结构,就像在9,10),提供灵活性处理同行离职,但是好的一般同龄人之间的连接通常不实现。已经有许多研究如何组织同行在一个高效和可扩展的方式。在[11接收器被组织成一个层次结构的有限的集群和多播树建基于此。在[12]同行被组织成一个有向无环图,使同行获得位置意识以分布式的方式。提高文件共享bt协议的性能,一个同行的覆盖网络被分为集群根据他们的距离提出了(13]。尽管一些解决方案已被证明其功能与有线连接,这些可能不适合移动环境。

初步结果描述的移动P2P系统在本文发表在14]。在以下部分中了解更多关于系统是由详细解释扩展实时流协议(RTSP) [15]消息用于信号和提供更多的实验结果。

3所示。一般系统概述

系统的体系结构设计为可伸缩的和高效的实时流媒体服务在移动环境。系统同时支持视频点播流媒体服务和生活。位置识别的同伴接近被利用来减少延迟,因此,提高系统的可伸缩性。

同伴被分组到集群根据他们接近为了有效地对等体之间交换数据。视频点播流媒体服务,集群可以构造为例,基于兴趣水平对于某些数据,以便同行看相同的部分视频同时属于同一集群。直播服务集群只能近距离的基础上形成的同行,因为所有同行感兴趣相同的数据块在同一时间窗口。集群还将帮助同伴维护的可伸缩性问题。同龄人在一个集群被认为是相互接近,因此同行之间的交流可以更有效地完成。

所有覆盖网络操作系统中使用扩展实现RTSP消息。所有RTSP方法扩展到包括一个额外的RTP2P-v1标签的需要头字段。这个标签可以接收点检测,支持实时P2P扩展是必要的。此外,所有RTSP将包含一个消息peer id头字段指示消息的来源。最重要的新头字段覆盖并广泛应用于覆盖网络操作。的用法覆盖头字段和其他额外的头字段根据消息类型部分中解释4和7。的语法peer id和覆盖头字段扩充Backus-Naur形式(ABNF) [16下面给出:

RTSP统一资源定位符(URL)是根据ABNF语法格式如下所示。的主机和港口部分中定义(17,部分]。的服务id指定了服务和stream-id指定了RTP会话。就像在15),也可以使用星号字符而不是URL意味着请求并不适用于任何特定的资源:

同行之间实际的媒体数据交换彼此使用RTP。系统使用基于时间的组块,从一个原始RTP会话创建多个局部流。这实现了多源流的方式,每个发送方发送的数据从一个不同的部分。源将有助于应对移动对等点和分配带宽的动态系统中使用更加灵活和均匀。原始数据流源生成也RTP RTP交付时间戳和序列号码。时间戳和序列号码不变在流媒体服务交付。这样做是为了让RTP数据包从多个局部流在正确的顺序重新组装顺序在每个对等为本地回放。RTP的时间线是已知的系统,因此可以用来唯一地标识单个包的时间戳在流媒体服务。

4所示。覆盖网络体系结构

覆盖网络的体系结构和三个集群共享一定的流媒体服务,如直播频道或视频点播电影,呈现在图1。应该注意的是,对于每一个不同的流媒体服务这样一个覆盖网络单独维护。服务发现服务器(SDS)是一个包含信息中心非移动服务器集群层次和系统中可用的流媒体服务。

当同伴想要加入P2P覆盖网络,同行的标识符(ID)首次从SDS使用要求RTSP选项消息,该消息带有一个new_peer_id标签的覆盖头字段。因为点没有点ID,它必须将值设置为- 1选项消息。一个独特的同行然后返回的SDS使用ID200好了消息,该消息带有一个New-Peer-Id头字段。的语法New-Peer-Id头字段ABNF如下所示:

集群概念的帮助下实现集群领袖(CLs)。有一个CL分配给每个集群与一个或多个备份集群的可能性领导人(名)。CLs是用来管理集群内同行和连接新到达的同行。每个普通的同伴必须执行定期保持活着消息通知其存在的CL和所有其他同行已收到RTP数据包。后者做是为了避免不必要的数据传输,因为RTP使用用户数据报协议(UDP)和发送端不知道接收端仍在网络。到达一个新的同伴可以选择一个合适的集群根据其最佳位置的知识使用往返时间(RTT)值与CLs本身。

除了RTT测量,可以基于位置识别,例如,IP水平跳数,地理位置或提到的这三个组合指标。IP水平跳跃数并不是唯一适合近距离度量,因为与虚拟私有网络(vpn)或其他隧道技术一跳实际上可能包括大量的啤酒花和距离可以很长。小跳数保证IP水平小也不拖延,因为它没有考虑到连接速度。地理位置也是在IP水平存在问题的观点。即使同行地理上彼此接近,IP路由路径将会循环通过遥远的路由器。因此,只有接近RTT值是用于我们的系统检查。

CLs是节点与合适的功能,如高吞吐量访问网络连接,足够的内存和CPU能力,期盼已久的电池寿命。一个集群应该只包含有限数量的同行为了维持系统的可伸缩性。CL收集统计数据的同行参与一个集群。这个统计数据包含关于服务加入时间的信息,接收缓冲区的位置,失踪的RTP包,和上游和下游连接,可以用来做决定的最好的同伴开始下载数据。例如,统计信息可以用来过滤候选人来源同行已经有很多上游连接或很多失踪的RTP数据包。服务加入时间可以用来估计同伴的行为。如果服务的同行加入了很长一段时间前,它是最有可能的一个稳定的同行也将在未来提供数据。另一方面,没有额外的信息将与移动设备的电池寿命,长期服务加入时间也意味着短料电池寿命。

CL是一个功能实体的网络也可以作为一个普通的同行参加同时,接收和发送媒体数据。因此,CL可以被视为一个普通的对等的功能扩展。CL将告知目前每隔十秒的SDS集群通过发送一个的变化选项消息,一个更新标签的覆盖头字段为了维护一个最新的集群在SDS列表。更新后的集群信息将使用可扩展标记语言(XML)表示(18]。减少网络中传送的数据量,压缩使用所有XML片段缩小从zlib压缩机制数据压缩库(19]。

虽然加入选择的集群,同行接收初始列表的同行可以获得实际的媒体数据。自然,相应的CL将加入同行插入同行列表,如果同行的数量非常大,同行的CL只能返回一个子集。接近集群测试以来的朋友的选择是可选的选拔程序保证同行相当接近对方。不管怎样,最终选择的来源的对等流,需要测试一定数量的同行,直到找到合适的。点以后可以收到更新的点列表在执行定期保持活着的消息CL,确保对等列表可以保持最新的流媒体服务。

同行的联系信息,联系同行所需的所有信息,也可能包括一个集群ID,以便同行内优先连接自己的集群。然而,应该是同行之间的数据连接位于不同的集群。这将确保集群不会成为独立的岛屿只有一个传入的连接与其他集群,这将形成一个单点故障,可能会导致问题稍后当同伴离开了流媒体服务。

4.1。服务创建和初始集群

消息交换在服务创建呈现在图2。当同伴们想要创建一个服务,一个宣布消息将被发送到SDS。一个client端口头字段显示的端口号用于覆盖通信。服务描述使用会话描述协议(SDP) [20.]。两个新的SDP属性,服务型和stream-info用于信号服务信息。的服务型属性定义了服务的类型,stream-info属性定义了RTP会话的标识符和参数中使用RTP会话分区部分中解释7。的语法服务型和stream-info属性和client端口头字段下面给出ABNF时:

作为应对成功的会话创建200好了SDS消息发送。消息包含了Cluster-Id和服务id头字段描述初始集群id和新创建的服务,分别。一个301永久移动消息也可以发送如果SDS已经搬到另一个位置。在一个重定向的情况下位置头字段必须出现通知SDS的新位置。任何其他消息类型必须被视为一个会话创建失败。的语法Cluster-Id和服务id在下面给出ABNF头字段:

创建初始集群有两种可能性,并为其选择一个CL: (a)第一同行加入服务将被指派为CL SDS,和(b)的原始数据源将会是第一个CL服务。后者可能使用更多的资源从原始数据源,因此原始数据源从CL责任在可能的情况下应被释放。然而,后者的可能性也保证初始集群仍然操作因为第一个加入同行可能很快离开服务。因此,另一种(b)是用于我们的系统。

成功创建服务时,最初的原始数据源变得CL集群,这没有消息类型的虚线所示图2,开始等待其他同行加入服务。当新同事加入服务,名由使用一个指定CL选项消息,该消息带有一个备份标签的覆盖头字段。如果同伴接受BCL分配,它发送一个200好了消息,如果没有,它会发送一个403年被禁止的消息。

使用一个服务更新和删除宣布消息。如果部分信息已经改变,SDS更新数据库中的信息。删除服务,SDP的停止时间t-line应设置小于当前系统时间,这意味着服务已经停止和SDS可以从数据库中删除服务。一个成功的服务更新或删除SDS会响应一个200好了消息,否则SDS将返回400年糟糕的请求或404 Not Found消息。

4.2。集群领袖离开

CL离开网络的时候需要取而代之的是其中一名。如果集群没有一个活跃的CL,新同事不能接受到网络。然而,这不会影响现有的同龄人之间的数据流连接,因为流和覆盖连接是独立的。不能发现的新同事正常的同龄人在集群领袖改变,但这应该不是一个问题,因为同龄人应该了解更多同行比他们使用。

事件的消息交换的不受控制的CL离开呈现在图3。当BCL不应对其期刊GET_PARAMETER消息,它的结论是,CL使得从集群和接触SDS使用选项消息,一个更新标签的覆盖头字段来取代旧的CL。第一次收到的来源选项消息将被指定为一个新的CL,说明了图中的虚线没有消息类型,和新到达的同行可以正常开始使用新的CL。所有其他名会收到301永久移动信息与新CL和将发送一个信息选项消息的join_bcl标签的覆盖头字段到新的CL BCL的作用并将继续。如果原始CL尚未离开了集群但有连接问题,它被重定向到新的SDS CL。在这种情况下,旧CL变成了基类库。

当同伴们注意到CL不可用,它试图连接到已知的名。如果基类库已经取代了旧的CL,它接受的连接200好了消息,否则它发送一个301永久移动消息的位置头字段指示的位置最后为人所知的CL。应该注意到,CL离开不是一个原子操作,需要一些时间,因此可以有短的时候,任何一个名不知道正确的集群的CL。如果列表中没有一名回应,SDS的同伴发送一个查询并要求一个新的集群可以加入。

4.3。集群分裂和合并

当集群增长太大是由一个单一的CL,集群应该分成两个单独的集群。现有的CL分配其中一名新集群,成为一个新的CL和重定向的现有同行新的集群。成功的集群中的消息交换分裂过程呈现在图4。

通过使用一个集群执行分裂选项消息的分裂标签的覆盖头字段。收到这个消息后,BCL将通知SDS,想成为一个新的集群的CL发送一个选项消息,该消息带有一个创建标签的覆盖头字段。成功创建集群,SDS会响应一个200好了消息,其中包含一个Cluster-Id头字段描述新集群的ID。否则,将返回一个SDS400错误请求消息如果请求消息格式是无效的,或者一个404没有找到消息如果服务不可用了。BCL集群创建成功后,将成为新集群的CL和分裂CL通过发送一个回复200好了消息,否则必须发送一个400错误请求消息分解CL,等待进一步指示。

分裂CL然后发送重定向消息,新CL的位置位置头字段的同行应该改变集群。重定向的同行会加入新的集群通过发送一个选项消息新CL。集群连接成功后,对方收到了200好了消息从新的CL,同行会发送一个200好了信息分裂CL。否则,同行会发送一个400错误请求消息通知,是不可能加入到新的集群。

创建CLs之间的重叠连接成功后通过发送一个分裂选项消息,该消息带有一个join_neighbor标签的覆盖头字段和一个200好了消息。这个连接随后被用来交换集群信息表示相邻的簇之间使用XML片段。

合并两个集群时,必须做一个集群变得太小了。如果同行的数量太小,一个新加入同行会得到一个非常小的不可靠的数据源列表使功能当其中一个同事离开服务。集群中的消息交换成功的合并过程呈现在图5。

合并由CL开始,当集群中的同行的数量低于一些预定义的阈值,通过发送一个重定向信息集群中的所有同行。同行会加入新的集群,选择从邻国合并CL集群,通过发送一个选项消息新CL。集群连接成功后,对方将会发送一个200好了信息合并CL。如果重定向同行没有收到任何新的CL或它接收的响应400错误请求信息,它必须发送一个400错误请求消息合并CL通知是不可能加入到新的集群,等待进一步指令。

在集群中的所有同行确认集群改变,合并CL将删除集群通过发送一个选项消息,该消息带有一个删除标签的覆盖SDS头字段。这个信息是可选的,因为集群移除也自动如果keepalive消息尚未得到在一定时间间隔内。成功的集群移除,SDS会响应一个200好了消息。否则,将返回一个SDS400错误请求消息如果请求消息格式是无效的,或者一个404没有找到消息如果集群不可用了。然后合并CL本身必须发送一个集群加入信息,也就是说,一个选项消息,该消息带有一个join_bcl标签的覆盖头字段,到一个已知的邻居并加入作为基类库。

所有覆盖网络互联是通过发送GET_PARAMETER和200好了消息同行之间保持活着的消息。邻国之间保持活着的消息交换CLs每隔20秒,用于交换信息的邻近的集群。CL和BCL之间保持活着的消息用于集群信息交付给BCL这些消息被发送每隔30秒。

5。部分RTP流

为了有独特的发送插槽的来源,部分介绍了RTP流的概念。首先,每一个RTP会话,如视频、音频和字幕流整个多媒体会话的沿着时间轴分成小块。每个部分都有一个固定的时间这是表示。开始时间是与RTP的开始时间时间基础,也就是说,开始的第一块位于RTP的起源时间线。以时间为单位的好处之一是,所有数据包在RTP层可以保持不变。分割在RTP数据包级别不需要创建局部流。这大大降低了实现的复杂度。

在第二步中,RTP数据包属于被分配到每一个RTP会话部分流根据(1),表示部分的索引流和表示RTP进行RTP数据包的时间戳。算法允许分配每一个RTP数据包在会话中部分RTP流,而无需维护国家同行本身。只有通过分析RTP时间戳结合常数参数是充分的识别部分流RTP数据包分配。假设一个RTP会议的时间表,这个过程如图6,在那里是用来表示周期:

请注意,块的大小应该选择以这样一种方式,它是大到足以包含至少一个RTP数据包平均。如果是选择太小,不会每一块数据,在极端情况下可能导致空部分的流。另一方面,大周期导致更长的启动时间,因为一个完整的周期需要缓冲无缝播放之前可以得到保证。在一个特定类型的划分,每一个将从一个intracoded图片。这将促进独立解码部分流的丢包是因为部分没有被收到。举例来说这可能很容易地通过调整的部分group-of-picture(共和党)的边界。增强鲁棒性也将通过分配键(RTP)数据包到多个泛音。关键数据包例如可以瞬时解码刷新(IDR)图片数据或其他数据,帮助错误隐藏。重复的RTP数据包会被删除在接待,因此不会影响基本算法及其复杂性。

部分流的数量,,可以改变每RTP会话。例如它可能不是非常有用的一个音频流分割成较低的比特率部分流如果整个RTP的比特率音频会话已经是一个数量级的部分RTP视频。这也收到额外的优势,音频全部或没有,从而减少恼人声响工件的局部流损失。

部分流的数量不一定需要恒定的整个P2P网络在一个特定的流媒体服务。事实上,有可能有所不同在每一个转发对等网络中。然而,选择相同的整个网络简化了分区功能的设计。

6。媒体传递机制

所有同行的流媒体网络正在形成一个无网格结构。同行是连接到其他几个同事和接收数据和发送数据到多个其他同行。网格布局图中可以看到一个示例1。

同伴可以请求一个或多个部分的交付流从另一个同伴。部分为流媒体流是最小的粒度,即对等不得流部分流的一小部分。部分流的数量可以调整实现部分流程的目标比特率。每个对等网络中应该有足够的上行带宽能够流至少一个部分。

在这种流媒体网络,大多数同龄人都来自同一集群中,某种形式的情报,以避免循环是必需的。这样的循环发生当一个发送者开始接受自己的数据通过一个中间数同龄人在网状网络。为了避免循环,一个算法基于流路径列表的形式使用的祖先。应用程序级的数据流的路径包含同行IDs转发流交付使用的贡献来源(中国证监会)RTP包的列表。然后使用该列表来避免接受来自同龄人的连接已经在减少连接的列表,如果一个同行通知列表中。

图7说明了媒体交付四个同伴。每个同行之间的箭头表示一个活跃的RTP会话,和方向定义了数据流的方向。采购同行可以发送多个局部流到一个特定的接收同行。这允许一个更小的粒度之间的速度适应网络中两个人同行。这些多个局部流可能是流在一个RTP会话或单独的RTP会话。同行的图编号和颜色。数字越小,越早同行加入网络;在这种情况下,同行第一是最初的来源。不同的颜色在同行缓冲区显示接收的数据的来源。为简单起见,四个值用于为每个对等泛音的数量。

为了得到一个完整的流,同行必须收到所有部分流;在这个例子中,泛音0,1,2,3。同行2号从原始数据源接收所有的泛音,也就是说,同行第一,并转发泛音同行第三,四,五。同行3号4号也收到来自同行的泛音,从同事和同行5号3号和4。所有传入数据包的所有部分流,构成特定的RTP会话被添加到一个单独的缓冲池。这个缓冲池维护关于目的地的信息对等,传入的数据包需要转发。每个传入的数据包检查和分配给其中一个输出队列。同行是在本地播放收到流,当地的球员被认为是一个目的地。

特定的接收发送的数据包对等传输的RTP从缓冲区队列就收到了。在本地播放的情况下,即接收同行解码和呈现了RTP会话,数据包也转发内部媒体播放器。缓冲需要从同伴离职和间接恢复丢失的数据。点可以要求更换点发送丢失的数据的缓冲区。还有一个可能性,同行没有特定部分可用的缓冲区因为糟糕的网络条件,例如,带宽不足。如果需要这些部件可能会稍后下载。由于缺失的数据,回放打断了这一时期,这取决于使用的编解码器缺失的数据将如何影响质量的经验(体验质量)。数据很可能不会及时订单或来自所有来源不同来源之间的拖延可能非常不同,所以缓冲也需要收集所有来自不同部分的数据流和排列顺序的数据传递到当地的媒体播放器。

当所有部分收到流几乎在同一时间,可以减少缓冲延迟和数据可以早些时候通过媒体播放器。然而,这种情况可能会改变在时间和一个常数缓冲延迟目前使用的实现。数据缓冲呈现在图8。播放缓冲区缓冲位于媒体播放器。当同行媒体消费,同时接收缓冲区共享与其他同行。从内容生成的总延迟接收回放是网络延迟的总和,缓冲延迟,媒体播放器播放延迟。

除了接收缓冲区,通过应该使用缓存数据存储在一个视频点播流媒体服务。当使用缓存,可以分布式视频点播数据从原始数据源。这有助于减轻网络负载从原始数据源,随着新节点加入网络能够从多个来源下载视频点播内容而不是依赖于原始数据源。缓存可以实现在许多方面,在最简单的模型中所有同行存储所有数据消耗。如果同行没有足够的存储容量,属于特定部分的数据流可以被缓存。此外,同伴可以限制缓存的数据采用滑动时间窗口。在前一种情况中,一个算法基于对等IDs可以用来确定哪些部分应该存储。这种局部缓存要求同行在流媒体服务的数量是相当高的。以确保数据可用性从多个同行在每一情况下,支持节点,充当流中继节点,可以用来存储所有的数据。这种继电器节点只存储数据并将其传递给其他网络参与者。 It should be noted that a support node also consumes upload bandwidth from other peers, but with a high throughput network connection it provides more bandwidth to others than it consumes. The currently existing simple VoD implementation uses the simplest caching model, which is of course not the most optimal one, but it enabled a fast proof-of-concept implementation.

7所示。对等操作服务

图9显示了消息交换,以防同行参与特定服务。获取所有可用服务的列表描述消息被发送到SDS。在获得的服务列表信息200好了消息只包含通用信息服务,减少消息的大小和信息表示为XML片段。如果用户希望搜索服务与一个通配符字符串,可以用来提供一个搜索元素通配符字符串SDS。如果没有可用的服务,SDS会回复的404没有找到消息。

能够加入到一个特定的服务,更详细的服务信息必须从SDS检索使用描述消息的RTSP URL指定服务。一个200好了消息只包含部分列出可用的集群,如果创建了大量的集群。响应使用多部分的MIME (21),因为它必须交付的SDP服务和XML格式的初始集群列表。如果服务不可用了,204没有内容SDS的消息将被发送。

获得SDS的CL列表后,同行使接触几个CLs,直到发现一个合适的CL。为此,同伴发送一个GET_PARAMETER消息CL和RTT计数器开始。同行停止RTT柜台接收200好了消息和比较了一些预定义的RTT值上限。第一CL的RTT值低于限制然后选为服务的CL。

通过发送一个同行加入选择的集群选项消息,该消息带有一个join_peer标签的覆盖头字段的CL集群。在200好了收到消息,最初的对等列表以XML格式如果一些同行已经加入了集群。否则,一个Cluster-Id头字段用于描述为集群ID。初始点的列表是一个随机子集总点集,如果集群中有很多同行。

同行试图请求数据从其他同行使用列表中的顺序设置消息。这个消息处理的配置对RTP接待使用UDP端口号运输头字段。如果有同行比部分流的目标数少,同行继续请求再次从一开始的列表,这样它会收到多个局部流从一个对等。如果某些同行没有响应,它从内部将被删除知道同行列表,所以同行不会再次尝试重新连接。接收请求流的对等,也就是说,音频或视频,会响应一个200好了消息表明它可能得到同行的流数据。

设置部分的RTP流是通过发送玩消息接收请求流的对等。分裂的原始RTP会话部分流部分中解释5,这些部分的流参数表示使用Partial-Stream头字段。的格式Partial-Stream头字段ABNF如下所示:

如果对方能够发送请求的泛音,它会回复的200好了消息。如果同行注意到一个循环,它将与一个响应400错误请求消息,如果对方不能发送请求的泛音,它会回复的404没有找到消息。后200好了信息,数据交付请求的同行使用RTP是开始。如果连续两个RTP数据包之间的时间间隔超过预定义的最大允许延迟,接收端应该得出这样的结论:发送端无法显示数据在时间和它应该改变发送方的部分问题。

同伴可以离开网络在两个方面。控制出发,同行通知邻国和CL离开网络。对方发送一个选项消息,该消息带有一个离开,标签覆盖头字段的CL,拆卸消息的数据交付的邻居。邻居,知道他们可以终止发送数据的RTP会话。也同行,接收数据知道他们将无法获得更多数据从同行,并可以搜索替换。的拆卸信息对等时也会发送通知,有一个循环的数据交付部分流。

注意到一个不受控制的同伴离开CL和发送数据到离开对等连接保持活着的消息后,也就是说,GET_PARAMETER没有收到消息,在一段时间间隔。目前,保持活着的消息被发送每隔30秒对CL和每隔15秒发送数据的对等。如果发送同行不接受维持消息间隔30秒内它的结论是,接收同伴离开,并终止了RTP会话。同样,如果CL没有收到任何消息从对等45秒间隔内得出结论:接收点已经离开并移除点从集群,因为缺乏运动。接收的数据离开对等会注意到不受控制的离职后,没有收到任何RTP数据包秒。的值应定义,这样可以得到的数据替换同行在接收缓冲时间,以避免干扰。这基本上是同样的情况当发送对等是不能够交付时间和当前的数据根据计算(2)。这个值由两部分之间的间隔时间属于同一部分的RTP流,正常的网络延迟可以从RTSP对请求-响应计算,和一个小额外的时间给同行补丁可能仍然被转发数据包的网络:

请求的数据替换同伴从一个特定的起点,一个Packet-Range头字段可以包含到一个玩消息使用RTP序列数字信号后的值。的Packet-Range头字段还可以用于信号当前播放位置,当同龄人正在寻求一个新的回放位置在视频点播服务。的格式Packet-Range在下面给出ABNF头字段。可以区分这两种不同的用例中使用的符号前的例子:

在视频点播服务,另外两个额外的头字段需要寻求操作。所需的寻道时间以毫秒为单位将信号使用寻求头字段。一个Fast-Send头字段将被用来通知发送方发送指定的数据量(以毫秒为单位)尽快能够填补接收缓冲区并开始播放以尽可能小的延迟。的格式寻求和一个Fast-Send在下面给出ABNF头字段:

8。实现

实时P2P流媒体的架构(RTP2P)应用程序呈现在图10。RTP2P应用程序是使用c++实现,它由十个不同的软件组件。原理图中是,更高的层使用立即低于它的所有组件,因此,例如,图形用户界面(GUI)使用服务,常见的,和媒体播放器组件。

GUI实现使用gtkmm框架(22Linux桌面环境和maemomm框架(23为Nokia N800)互联网平板电脑。目前三种不同的媒体播放器,VLC [24),媒体播放器(25],GStreamer [26),需要在应用程序中。这是必要的,因为任何一个球员不能提供我们的应用程序所需的所有特性。VLC用于流RTP数据包本地RTP2P应用程序的原始数据源。原始数据源只听本地套接字,并接收RTP数据包生成的VLC,可以向前进一步使用源流概念解释部分5和6。媒体播放的媒体播放器使用客户端应用程序。还可以使用VLC媒体播放,但随着媒体播放器可以实现更好的同步与多个基本流利用媒体服务器发送方报告。GStreamer是用来创建一个RTP流N800的摄像头设备。所需的RTP GNU ccRTP库提供的操作(27]。此外,Boost库(28)用于线程的时间和文件系统操作。

其他专有软件组件,服务,覆盖,流媒体,XML, RTSP,常见,SDP,形式对等的基础操作。SDP组件是基于GNU oSIP图书馆(29日),用于解析表达的流媒体服务描述SDP格式。通用组件包含其他组件广泛应用的定义和功能包括,例如,线程和套接字操作。XML组件是基于海外XML解析器(30.),这是用于解析集群和服务信息以XML格式表示。RTSP组件包含RTSP消息创建和解析和RTSP操作的基本功能,增强和利用流媒体和覆盖组件。流组件包括发送方和接收方的功能来处理P2P RTSP通信和RTP流媒体服务的接收和发送操作。的功能包括集群领袖和所有RTSP覆盖通信覆盖组件。服务组件包含需要加入的功能,创建和管理流媒体服务。

图11介绍了GUI在诺基亚N800设备。GUI包含三个部分:(a)主应用程序和主要观点,信息和球员选项卡,(b)创建、连接、列表和首选项对话框从下拉菜单中,发射和(c)底部工具栏按钮启动和停止在接收端所选择的服务,在原始数据源和服务。列表对话框用于获取服务列表所示的SDS然后主要选项卡。采购信息服务也主要标签所示。Info选项卡用于显示详细的服务信息服务和采购服务,目前由同行接收。球员选项卡显示原始数据源的采购流程和当前收到同行的流。连接对话框用于输入IP地址或连接到SDS的域名。创建对话框是用于创建新的服务。服务名称、类型和用户给出的描述,以及文件的存储内容。捕获的内容也可以直接从相机。 The Preferences dialog can be used to adjust some attributes, for example, port numbers for the network traffic and the level of debug messaging.

9。绩效评估

评估的测试设置的操作系统在移动环境中呈现在图12。四个诺基亚N800互联网平板电脑HSDPA网络连接提供的Nokia E90被作为SDS与电脑一起使用。在一些测试用例,也另一个电脑作为一个原始数据源。在测试一个特殊的应用程序是用于监测流媒体同行之间的连接。像大多数普通消费者连接,也移动连接遭受网络地址转换(NAT)建立连接限制因为互联网服务提供商(isp)不希望用户使用移动带宽相对较小的托管服务或使用P2P技术。为了避免连接限制,与VPN解决方案的解决方案是利用。每一个实体与限制网络连接首先创建一个VPN连接服务器并获取所需的自由通过VPN隧道连接。一个更永久的解决方案可以使用NAT实现遍历克服这些限制。

测试表明,系统执行超过移动连接初始缓冲时间10秒。缓冲区的大小在我们的应用程序中也是十秒由于使用RTP和缓冲区大小相比相对较小的现有解决方案报告(4]。

因为可用的移动设备的数量是有限的,一个实验室网络环境与17个台式电脑(英特尔Core2Duo E6550, 4 GB的DDR2,运行Linux CentOS,内核2.6.18 PAE)被用来测试系统功能更大数量的同行。16主机被用来运行40同龄人在一起每个主机一个主机都扮演SDS和作为原始数据源。提供的所有设备之间的连接是1 Gbps开关。一个直播服务的长度是大约一个小时,所有即将到来的数据平均值从五个不同的流媒体服务。最大的集群大小被设置到30或70同行,和同伴始于40 5 s开始间隔周期:第一个同伴开始在每个主机,然后第二个等等。

9.1。稳定的网络

在这个测试场景中的所有同行保持稳步服务的加入时间的服务。加入时间的流媒体服务,覆盖加入时间加上初始缓冲时间,作为一个函数的覆盖规模呈现在图13。从图我们可以看到初始缓冲时间仍然几乎不变不管同行在网络的数量。覆盖加入时间的增加可以最小化通过改善当前集群选择算法。

发送和接收RTSP数据字节的数量每点的函数覆盖尺寸如图14。合并后的原始RTP会话的比特率约为112 kbps,使用FFmpeg编码的31日]h +视频和AAC音频编解码器。因此,RTSP信令开销最小的比实际的媒体数据。更大数量的RSTP数据的原因是由于相对较大的集群发送状态信息消息传播的SDS CLs。图之间的主要区别(14日)和图14 (b)轻微增加RTSP信号数据300年以后同行的最大集群大小30同行。这是由于较大的(增加)的集群和集群状态信息的消息。类似的效果可能发生的最大的集群大小70年同行的同事增加高于当前使用的最大值。

(一)

(b)

9.2。网络离开和重新加入

模拟甚至更现实的情况和真正的移动造成的生产节点,一个计时器功能,能够随机关闭并重新启动节点使用。同行加入了服务之后,它在随机从30年代到10分钟的服务,然后离开了服务,加入后10年代。这允许我们测试网络在更现实的情况下,同行离开和数据连接失败。

发送和接收RTSP数据字节的数量每对等的功能覆盖规模呈现在图15。如果我们比较这些值和相应的值在稳态情况下,我们可以看到值遵循相同的趋势,但更换点搜索和点重新加入消息引起小总体增加信号数据。

10。未来的发展

在当前叠加实现中,集群变化是控制的CL。Peer-controlled集群变化,同行更改集群后获得一个新的集群知识从而更好地服务于数据需求,将会使系统更具有可伸缩性,并提高整体性能。

集群目前周边CLs之间的松散连接在一起分享一些同行的信息。更清晰的集群组织结构与集群组长(#)是值得研究的。#可以收集信息集群中的所有集群组SDS和集群发送更新消息,而不是从个人CLs单独的更新消息。这个组织成n层的层次结构可以增加网络可伸缩性和减少覆盖以来加入集群的搜索时间就会减少来。缺点,系统的复杂性和覆盖维护将高度增加。

更先进的实现级别支持流媒体视频点播等更好的缓存机制和支持其他录影带记录(VCR)像快进和回放功能,除了目前现有寻求功能肯定会提出不同的要求相比,直播的情况。机制处理数据包损失是点对点传输技术的一个重要研究领域。不同误差鲁棒性技术,如简单的重传,前向纠错(FEC)和网络编码,需要研究发现这些技术的优缺点,使用时除了当前机制基于对等替换之前接收缓冲区下溢。

一个有趣的研究领域是使用多描述编码(MDC) (32)或可伸缩视频编码(SVC) [33]在P2P实时流媒体也提出了在10]。单个流分为几个单独描述和每个描述然后转发到网络中。使用这种方法,当前部分流可以被描述在不影响集群覆盖网络体系结构。然而,我们的部分流概念复杂性更低(比MDC或SVC),这使得快速概念验证的实现。我们的设计允许一个简单的替换部分流的概念与MDC或SVC尽快实施成为公开的。

11。结论

移动环境下的有效实时的P2P流媒体系统提出了传统的基于客户端-服务器的流媒体应用程序是一个替代解决方案。一个可伸缩的覆盖网络组同事到集群根据他们的距离是创建和维护使用扩展RTSP消息集群领导人的帮助下一个服务发现服务器。此外,实际的媒体交付使用部分实现RTP流的概念。RTP会话是分成许多部分流以这样一种方式,它允许重组原始媒体实时会话在接收端。

第一个实验室测试的测试在移动环境中显示当前实现表现良好,并提供非常低的初始缓冲时间。更先进的实验室检测与同行之间的不同的延迟和吞吐量仍然需要强调系统瓶颈和可用性问题。

确认

作者要感谢•范Gassel,亚历克斯Jantunen和马可Saukko有价值的工作,作为开发团队的一部分。这项工作被泰克部分支持未来网络计划的一部分芬兰战略中心科学、技术和创新领域的ICT (TIVIT)。

引用

“YouTube-Broadcast你自己”,2009年5月,http://www.youtube.com/。视图:谷歌学术搜索
“Octoshape”, 2009年5月,http://www.octoshape.com/。视图:谷歌学术搜索
“SopCast”, 2009年5月,http://www.sopcast.org/。视图:谷歌学术搜索
j . Peltotalo j . Harju a Jantunen et al .,“p2p流媒体技术的调查,”学报》第七届国际会议上网络(ICN ' 08)2008年4月,页342 - 350。视图:出版商的网站|谷歌学术搜索
h . Schulzrinne s Casner r·弗雷德里克·雅各布森和诉,“RTP实时应用程序的传输协议,”互联网工程任务组,RFC 3550, 2003年7月,http://www.rfc-editor.org/rfc/rfc3550.txt。视图:谷歌学术搜索
b·科恩“激励在bt,建立鲁棒性”点对点系统的经济学研讨会学报》(P2PECON ' 03)2003年6月,页116 - 121。视图:谷歌学术搜索
p·沙阿和肯尼迪。巴黎,“对等多媒体使用bt流,”学报》第26届IEEE国际性能、计算和通信会议(IPCC ' 07)2007年4月,页340 - 347。视图:出版商的网站|谷歌学术搜索
江x, y盾、徐d和b . Bhargava”GnuStream: P2P流媒体系统原型”多媒体和世博会的国际会议(ICME ' 03)2003年7月,页325 - 328。视图:谷歌学术搜索
张x, j . Liu李b和t·s·艾。p .百胜”CoolStreaming / DONet: p2p实时流媒体数据驱动的覆盖网络,”进行的24日联合年会IEEE计算机和通信的社会(INFOCOM 05),3卷,第2111 - 2102页,2005年3月。视图:谷歌学术搜索
n Magharei和r . Rejaie ':点对点receiver-drIven基于网格流,”学报》第26届IEEE计算机通信(INFOCOM ' 07)国际会议上2007年5月,页1415 - 1423。视图:出版商的网站|谷歌学术搜索
d . a . Tran k .华,t .做“锯齿形:一个高效的p2p流媒体方案,”学报的22日联合年会IEEE计算机和通信的社会(INFOCOM ' 03),2卷,第1292 - 1283页,2003年3月。视图:谷歌学术搜索
梁j . k . Nahrstedt”DagStream:局部性意识和弹性点对点传输失败,”第13届多媒体计算机和网络研讨会论文集(MMCN 06年)2006年1月,页224 - 238。视图:出版商的网站|谷歌学术搜索
Yu和m . Li“CBT: proximity-aware同行集群系统在大规模BitTorrent-like对等网络,”计算机通信没有,卷。31日。3、591 - 602年,2008页。视图:出版商的网站|谷歌学术搜索
j . Peltotalo j . Harju m . Saukko et al .,“实时移动网络环境中,p2p流媒体系统”《信息通信和移动视频研讨会交付(MoVID ' 09),2009年4月。视图:出版商的网站|谷歌学术搜索
h . Schulzrinne a . Rao, r . Lanphier“实时流协议(RTSP),”互联网工程任务组,RFC 2326, 1998年4月,http://www.rfc-editor.org/rfc/rfc2326.txt。视图:谷歌学术搜索
d·克罗克和p . Overell增强BNF语法规范:ABNF,“互联网工程任务组,RFC 2234, 1997年11月,http://www.rfc-editor.org/rfc/rfc2234.txt。视图:谷歌学术搜索
t·伯纳斯·李,r·菲尔丁和l . masint”“统一资源标识符(URI):通用语法”,互联网工程任务组,RFC 3986, 2005年1月,http://www.rfc-editor.org/rfc/rfc3986.txt。视图:谷歌学术搜索
W3C,可扩展标记语言(XML) 1.0World Wide Web Consortium (W3C),第四版,2006年版。
“zlib”, 2009年5月,http://zlib.net/。视图:谷歌学术搜索
m·汉德里和v .雅各布森SDP:会话描述协议”,互联网工程任务组,RFC 2327, 1998年4月,http://www.rfc-editor.org/rfc/rfc2327.txt。视图:谷歌学术搜索
k·摩尔,”MIME (Multipurpose Internet Mail Extensions)第二部分:消息头扩展非ascii文本,“互联网工程任务组,RFC 1522, 1993年9月,http://www.rfc-editor.org/rfc/rfc1522.txt。视图:谷歌学术搜索
“gtkmm-C为GTK + + +接口和GNOME,”2009年5月,http://www.gtkmm.org/。视图:谷歌学术搜索
“Maemo maemomm-C + +绑定API,”2009年5月,http://maemomm.garage.maemo.org/docs/index.html。视图:谷歌学术搜索
“VLC媒体播放器”,2009年5月,http://www.videolan.org/vlc/。视图:谷歌学术搜索
2009年5月,“MPlayer-The电影播放器http://www.mplayerhq.hu/。视图:谷歌学术搜索
“GStreamer:开源多媒体框架,”2009年5月,http://www.gstreamer.net/。视图:谷歌学术搜索
“GNU ccRTP-GNU电话”,2009年5月,http://www.gnu.org/software/ccrtp/。视图:谷歌学术搜索
“提高c++库”,2009年5月,http://www.boost.org/。视图:谷歌学术搜索
“GNU oSIP图书馆”,2009年5月,http://www.gnu.org/software/osip/osip.html。视图:谷歌学术搜索
“海外XML解析器”,2009年5月,http://expat.sourceforge.net/。视图:谷歌学术搜索
“FFmpeg”, 2009年5月,http://www.ffmpeg.org/。视图:谷歌学术搜索
v . k . Goyal“多重描述编码:压缩与网络”,IEEE信号处理杂志,18卷,不。5,74 - 93年,2001页。视图:出版商的网站|谷歌学术搜索
h·施瓦兹、d . Marpe和t . Wiegand”概述的可伸缩视频编码扩展h / AVC标准,“IEEE电路和系统视频技术,17卷,不。9日,第1120 - 1103页,2007年。视图:出版商的网站|谷歌学术搜索

国际期刊的数字多媒体广播