P2P流媒体视频点播系统的个人技术报告

项目说明

    来源为高等计算机网络的大作业设计。我们组选择的是p2p的流媒体视频点播系统。核心内容的是chord算法。

系统分析

    局域网内的任何结点既可以发送媒体压缩信息给其他结点,也可以从其他结点接收视频信息。此外流媒体信息是在网内从多源结点获取,而非单源模式。改变传统的需要中央服务器的查询支持,虽然本系统也需要一个中央服务器进行存储数据源以及节点加入的初始化,但是一旦节点加入了p2p网络,那么中央服务器的功能便会弱化很多,客户端peer可以利用其他peer节点已有的信息进行资源查询,而不用经过中央服务器。 在理论上,chord是一个纯p2p算法,但是在试验中我们发现,在广域网中实现一个完全对等的p2p网络是不大现实的一件事情,因为根据chord算法,节点的加入需要知道一个已知的节点信息,而这个节点信息无法像在局域网中可以通过广播的方式进行查询,也就是说这个已知的节点就是存在的中央服务器,所有的节点加入都需要知道中央服务器在网络中的位置,通过中央服务器加入到chord网络中。而在局域网中,必存在一个初始信息源,对于一个如上所描述的系统来说,这个初始信息源可以当成一个中央服务器,当然这个中央服务器的功能也被弱化很多。

项目设计与管理

    采用JAVA语言作为实现工具,并利用其UDT传输包实现数据传输、JMF视频播放工具包和openchord开源工具包,在局域网内实现基于P2P的流媒体视频点播系统。系统设计主要涉及的工作量包括:服务器端资源管理、P2P资源查询传输机制、客户端缓冲区管理和视频播放软件。预计的工作时间为1个月,总工作量为4人月。开发采用敏捷开发模型,进行迭代式开发,开发讨论为3天一次的站立会议,有效保障小组成员的信息一致性。会议中根据迭代需求列出一周或者近期的任务,小组成员互相监督管理,提高效率。能够有效的保障在规定的时间内完成项目。

功能需求

  • 客户端软件:运行客户端软件即获取所有频道列表信息,获取需要播放的文件信息,查询本地缓冲区,若已在本地有播放过,则直接进行本地播放;没有缓存的文件则将从可用的对等节点获取。

  • 缓冲区管理:P2P资源查询和分发资源服务器管理资源,使用chord协议获取得到资源存储节点,选择资源存储节点,使用多线程调度下载,提供分片信息给客户端软件。将视频分片组成队列,记录分片大小,若总的缓冲区大于500MB则根据队列顺序删除先到的分片。 服务器端:初始化资源,构建chord网络。其他peer节点加入服务器端的chord网络。

实现效率

    提高效率的方法包括:

  1. 使用多线程进行下载分片资源;
  2. 缓冲区大小管理,避免下载重复资源;
  3. 使用UDT传输,加快传输效率,简化系统复杂度。
  4. 同一资源节点的选择算法

类图

个人工作总结

项目管理

    我并不是第一次在项目中担任组长,但是这次的项目开发与以往有很大的不同。

  1. 组员之间互相都不熟悉,对对方了解什么技术,善于哪一个模块的开发都不了解。
  2. 工作时间不固定,而且特别的缺少,每个组员都有老师分配的任务和其他的课堂作业。
  3. 工作环境不理想,组员的实验室之间相隔较远,沟通不够方便
  4. 组员普遍对新技术不太了解,只是掌握基础知识,开发上存在困难。
  5. 没有明确的需求和系统边界。

    以上种种的一切都给开发造成困难,特别是第一条。因为对大家的开发水平和偏好都不了解,所以在分配任务的时候就相当与黑盒测试一般。 无法根据已知的情况安排任务。其他方面也给相互之间的沟通制造了困难。而沟通对于团队来说,我认为是比其他方面更加重要的。

    争对上述几条我对项目进行如下管理:

  1. 项目整体上为迭代开发,采用增量模型
  2. 建立qq群及时共享消息和资源
  3. 每周一次的例会,后来因为项目进展缓慢,改为3天一次
  4. 开会的时候借鉴敏捷站立会议的要点,给出任务需求,让组员选择
  5. 开发采用模块化的方法,预留API接口给使用者,明确代码责任制
  6. 采用git作为版本控制,所有代码再github上托管,组员可以pull和push最新更新

    但项目管理过程中还是有很多方面没有考虑到:

  • 发现开会的时候气氛不够浓烈,组员大多数时候没有提前做一些准备,导致开会时间过长
  • 自己的思想表达不够清楚,没有确定组员明白自己的想法
  • 在做架构的时候,没有做好调研工作,所选的方法并不一定时最佳的
  • 组员能力不了解的情况下,将组员能力的底线设置较高
  • 重点功能和说明没有采用图片或者文件保留
  • 开发过程中,没有很好的进行时间估计,导致很多应有的需求未能实现

开发总结

    我所负责的内容是缓冲区管理和系统架构的设计。开发过程中遇到的问题如下:

  1. 开发过于仓促,代码比较粗糙
  2. 在服务器端实现多个客户端接入进行多线程udp传输文件的时候遇到困难,未能很好的实现多线程
  3. 在带宽检测的那一块没有实现,还是因为没有合理规划时间,导致后期工作量大。
  4. 开发的时候没有进行很好的时间估计

收获还是有一些的:

  1. 对DHT的chord lookup sevice进一步了解
  2. 实现p2p流媒体的功能,了解其中的机制
  3. 巩固和复习了Java的语法和用法,较多的使用线程,提高效率
  4. 总体设计和分析上有了进一步的提高

参考文献

[1] P2P流媒体系统节点管理与数据分发机制. 王延伟. 山东大学硕士学位论文. 2010.
[2] Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications. Ion Stoica. etc. MIT Laboratory for Computer Science. 2001.
[3] Reducing Maintenance Overhead in Chord via Heterogeneity. Yuh-Jzer Joung. Jiaw-Chang Wang. Taipei. 2005

posted @ 2013-01-02 17:24  billowkiller  阅读(1280)  评论(0编辑  收藏  举报
Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.