Peercast的改进分析

Peercast可以说是一个实验的产品，而不是一个稳定的商业版本。所以无论在稳定性还是在性能上都存在一定的问题。这里提出Peercast存在的一些问题，并考虑相应的改进方法。希望可以为大家改进Peercast提供一些帮助。

先解释几个名词：
父节点：也就是此时你在向别人传输数据。一个节点可以同时是父节点和子节点。
子节点：也就是此时你在接收父节点传输给你的数据。

基于文件传输的流媒体传输：
    Peercast是在Gnutella协议的基础上发展而来的。Gnutella是一个P2P的文件共享系统，可以传输任何类型的文件。Peercast传输的文件是视/音频流，传输方式通过HTTP方式进行。但Peercast没有考虑到流媒体传输的特性，只是简单地用HTTP方式来传输视/音频文件。
    改进：可以考虑采用RTP/RTSP方式来传输流媒体数据

单点传输：
    Peercast每个节点的数据只能来源于单一的节点。这样的好处在于模型简单，缓冲机制容易处理，传输过程中不会产生太多的控制信息。在传输音频时没有任何问题，但是在传输视频数据时，由于视频数据量大，所以会经常出现缓冲很久的情况。
    单点传输还存在的一个问题是如果父节点退出网络，会对子节点造成很大的影响。其实单点传输可以理解为基于转播的传播方式，每个节点向其他结点转播频道。但这样的话无法发挥出一般P2P软件使用的用户越多传输速度越快的优势，这时候结点多只意味着你选择最佳节点的空间大而已，一旦确定一个传输节点，速率可以认为就是固定的。
    改进：采用多点传输的一种称为SwarmStreaming的方式。

节点的动态加入：
    有新节点加入时似乎其他节点也会受到相应的影响，如出现缓冲或声音出错等情况。
    这个问题尚在研究之中。

节点的动态退出：
    由于Peercast只能从一个结点传输数据，那么当你的传输节点退出网络的时候，就无法再连接到另一个传输节点了，而只能选择重新输入频道地址。这是由于Peercast并没有做相应的处理。如果节点动态加入和退出频繁的话，会带来很大的问题。
    改进：在一个节点要退出网络的时候，它先向它的子节点发出要退出的消息，子节点收到这个消息后，根据它的ChanHit再去寻找下一个传输者。如果在读完缓冲前能与另一个节点建立连接，就不会出现中断的情况。

电台发布：
    由于要支持各种各样的数据来源，如静态MP3文件、实时编码，各种不同类型的文件，所以电台发布繁琐。
    改进：可以在Peercast中内置电台发布功能。可以做成类似向导形式，也就是让你一步步地去选择发布的来源、方式、编码率等等。这样可以使软件更易使用。

YP：
    目前大多数的P2P软件都需要一个目录服务器，YP就相当于这样的一个目录服务器。
    也可以把显示频道的功能集成在Peercast软件中，只需要使客户端去读取YP上的频道信息就可以了。不过这样会增加Peercast的CPU使用率，而且由于电台的动态变化比较大，所以可以考虑在这边只显示YP上第一页的电台。

播放器集成：
    其实是否集成播放器各有各的好处。
    不集成播放器的好处在于用户可以使用他们喜欢的媒体播放器去播放相应的文件。
    集成播放器的话用户界面会更友好，可以显示出错和连接信息，而且看起来更像一个完整的软件。
    这个功能可以根据需要而定。