PeerCast系统介绍

 

PeerCast 系统介绍

1 概述

PeerCast^[1,2] 是开源的 P2P 流媒体软件， P2P 流媒体与传统的流媒体不同，没有集中的中央流媒体服务器，任一节点都可作为种子节点进行广播，每个节点在作为 Client 从别的节点接收媒体数据进行播放的同时，也要作为 Server 向其它节点提供服务，其服务质量随着整个网络节点数目的增加而提高，与传统的流媒体服务器相反。

目前 PeerCast 仅支持广播，暂不支持 VOD 形式的点播。支持的流媒体格式： MP3 、 WMA 、 AVS、WMV 和NSV等。

       本文主要介绍 PeerCast 的系统结构、工作流程、 P2P 算法以及存在的问题。

2 系统简介

2.1      系统结构

       PeerCast系统结构

系统主要由流媒体服务器（提供广播源）、 PeerCast （广播 / 中转）、播放器（播放 PeerCast 获得的媒体数据）和 Yellow Page （ 管理和显示频道信息） 组成。

Yellow Page 包括 PeerCast （不同与其他 PeerCast ，整个系统只有一个，负责组织、管理 PeerCast 之间的频道信息通讯）和频道 Web 页面（显示频道信息）两部分。

频道以广播源节点为根组成一个树状结构。

2.2      网络协议

PeerCast 网络协议

目前支持的流媒体协议有 HTTP 、 MMS 和 RTSP ，媒体源和广播的 PeerCast 之间使用这些协议连接。另外在播放器和本地 PeerCast 之间也使用和媒体源相同的协议，从本地 PeerCast 获取收到的数据、播放。

PeerCast 之间使用 PCP 协议（自定义协议），数据和路由信息均通过 PCP 协议传递， PCP 协议是在 TCP/UDP 传输层之上的应用层协议，目前系统传输层使用的是 TCP 协议。

Yellow Page 有 2 部分组成： PeerCast 和 Web 页面， PeerCast 管理整个系统 PeerCast 之间的频道信息通讯 ， Web 页面从 PeerCast 的特定端口读取以 XML 形式组织的频道信息，并将信息解析为 HTML ，发布在 Web 页面。

2.3      频道组织结构

PeerCast 频道组织结构

PeerCast 频道组织采用了树状结构，以频道源为根节点组成了应用层组播树。 频道源通过 Tracker 实现对外路由信息传递，频道源将频道信息广播到 Tracker ， Tracker 将收到的信息传递到 YP ，因此， YP 有全部频道的路由信息。 Tracker 用于连接广播源和 Yellow Page ，由网络中相对比较稳定的节点（比如广播源）组成。

3 工作流程

3.1      频道广播

频道广播

1.    创建频道，生成一个唯一的用 16 个字节表示的频道 ID ，分配频道缓冲区；

2.    与 Media Server 建立网络连接并开始接收数据；

3.    连接到 YP 获得 Tracker ；

4.    连接 Tracker ，发布频道信息（ ID 和 IP 等）；

5.    Tracker 将收到的频道信息广播到 YP ；

6.    Yellow Page 的 Web 页面访问 PeerCast(Yellow Page) 获得频道信息，以 HTML 形式发布。

3.2      频道中继

 

频道中继

1.       与上游节点（流媒体服务器或者别的 PeerCast 节点）建立网络连接，并接收频道的媒体数据包；

2.       将接收到的数据包放入该频道的循环缓冲队列；

3.       接收到下游节点（ 别的 PeerCast 节点或者本节点的媒体播放器 ）的连接请求后，向其发送循环缓冲队列中的数据包。

 

3.3      频道播放

频道广播

1.       从 YP 的 Web 页面看到某个频道，点击播放，系统将播放参数传递给 PeerCast ， PeerCast 向 YP 查询频道的位置；

2.       YP 根据路由表和路由选择算法返回多个频道源（可能是 Relay ）给 PeerCast ；

3.       与上游节点建立网络连接，将接收数据包放入循环缓冲队列；

4.       PeerCast 调用 Player ，将收到媒体数据映射为包含 URL 的媒体文件，并将地址传给 Player ， Player 通过此地址连接 PeerCast ，获取循环队列中的数据。

 

4 算法原理

4.1      路由协议传递

路由协议传递

 

 

一个 PeerCast 维护 4 类对外的连接： CRelay （ PeerCast 所看频道的上游或通过该 PeerCast 看频道的下游）、 COut(PeerCast 相连的 Tracker) 和 CIn(PeerCast 作为其他节点的 Tracker) 。与某个频道相关的路由信息（例如某个频道增加了观看者，即多了一个数据源提供者）在 CRelay 之间传递。新广播的频道和新增 Tracker( 某个节点成为 Tracker ，广播源节点有机会成为 Tracker) 的信息在 COut 和 CIn 之间传递。

路由信息通过频道的信息更新函数（broadcastTrackerUpdate ）定时产生，使用与其相连的PeerCast 向外传播，频道信息更新函数是路由信息传递的源动力。

4.2      查找算法

       YP收到请求某个频道的路由信息时，查询其路由表，根据最近最少使用和频道源节点的带宽容量，返回多个频道源地址。最近最少使用：距离上次访问时间差最长的节点。带宽容量：节点目前提供服务的带宽总和小于其设定带宽。

如果 YP 本身有被查找频道的数据，并且符合查找算法的要求， YP 将为请求端服务，创建发送对象从该频道的循环队列读数据发送给请求端。

查找算法流程图

查找算法流程图说明：

同一网络：使用内网 IP ，在一个网关（ NAT ）内的节点，这些节点的特点是对外连接使用同一个 IP 。

NAT 内节点：使用内网 IP 的节点，这些节点位于网关内，所以又称为防火墙内的节点。

发送连接信息到 NAT 内节点：由于使用内网 IP 的节点不能够接受外部连接，所以当请求频道的节点 IP 为外网 IP ，而频道源节点为内网 IP 时，将通过与频道源节点连接的 Tracker 给位于内网的频道源节点发送消息，通知有外网节点需要其媒体数据，频道源节点收到消息后主动向外网请求节点发起连接，传输媒体数据。这是穿越 NAT 的一种方法，由 NAT 内的节点主动发起连接。

4.3      离开/断线处理

4.3.1      路由表

通过 4.1 提到的路由传递机制，本地保存了与其相连的 PeerCast 发送的路由信息。在需要查找路由信息时，先查找本地路由表，如果没有则求助 YP 。

4.3.2      断线/离开

当检测到连接节点断线时，先查找本地路由表获得路由信息，连接新的接点；如果查找或连接失败，则连接到 YP 获得路由信息。

对离开没有进行单独处理，节点离开相当于断线。

5 问题和讨论

5.1      存在的问题

5.1.1      查找策略

目前的路由查找策略是最近最少使用和服务带宽容量相结合，没有考虑节点之间的延迟，根据延迟选择最佳节点。

5.1.2      断线/离开重连

断线 / 离开时，节点所服务的子节点各自处理，子节点查找本地的路由表或连接到 YP 获得频道源，连接新的频道源获取数据。这种处理增大了子节点的媒体中断时间，降低了收看的质量。

5.1.3      树的平衡

       算法在节点加入和离开时没有平衡树的结构，这将使树结构不平衡、层次比较高，从而增加了节点之间的传递延迟。

5.1.4      树型结构的缺点

树型结构的特点是节点仅从一个上游节点获取频道数据，不能很好的发挥 P2P 优势。

5.2      未来计划

PeerCast 尽管有一些问题和不完善的方面，但提供了一套完整的 P2P 流媒体解决方案，有很多可以借鉴的地方，比如频道发布和 Yellow Page 管理等。

在今后的研究中，计划在 PeerCast 基础上重构一个 P2P 演示平台。

平台有以下几个特点：

1.       系统架构松散，可扩展，能够运行多种 P2P 算法，以便于对比分析和研究算法。

2.       能够输出完备的测试信息，比如：媒体延迟、带宽占用、流畅度和掉线影响度等，通过这些信息可以量化 P2P 算法。

3.       基于 DirectShow 的播放器。目前对于标准的 ASF 和 WMV 等媒体源，使用 Windows Media Player 播放，对于基于 RTSP 的 AVS 频道源，使用 mpeg4ip 中的播放器播放，该播放器效率和稳定性不高。所以需要设计基于 DirectShow 的 AVS P2P 播放器。另外，可以将播放缓冲和 P2P 的缓冲相结合，提高播放流畅度，降低延迟和抖动。

 

6 参考资料

[1]      www.peercast.org

[2]      H. Deshpande, M. Bawa and H. Garcia-Molina, “Streaming Live Media over a Peer-to-Peer Network”, Stanford database group technical report (2001-20), Aug. 2001.