一套完整的P2P播放系统,由哪些模块构成呢?

一套完整的P2P播放系统,由哪些模块构成呢?

p2p影音技术为客户提供了越来越好的观看体验，边下边播、断点续播、节省带宽等，p2p影音播放系统越来越受用户喜爱，那么一套完整的一套完整的P2P播放系统,由哪些模块构成呢?不啰嗦！直接上干货：

[1] 视频播放客户端,一般需要一个P2P后台进程 + 一个前台播放器界面,包括浏览器插件 ,当然,后台是否自动启动,是否自动共享,是否在播放结束后自动退出等,这还是需要好好考虑的,毕竟后台进程影响用户体验,很容易被用户当成后门程序来对待.

[2] 资源发布服务器, 一般来说,我们建议采用类似BT这样的分块发布协议, 而不是以前曾经流行的xxvod那样以文件为基础的发布,以文件为基础的发布,针对小文件有效果,但是针对大文件,在发布初期效果很差,除非部署大量的服务器发布同一资源,否则必须等到用户端有大量的资源沉淀后才能逐渐改善,除非你有大量服务器进行发布,否则不建议采用以文件为基础的资源发布协议,这个服务器软件也同时可以提供给子站长发布他们的资源.

[3] 资源数据库服务器, 对bt来说,就是个种子, tracker, 但是这里我们建议你独立出来做个内存数据库服务程序,因为后续的P2P优化,用户端的检索等操作,都需要大量操作,如果采用固定的采集模式,那么用户端无法发布自己的共享[当然这不是个大问题], 其次子站长发布的资源数量一大,你会发现很难优化,会难以优化响应用户端的各种请求,其次如果要求用户端进行后台其他文件的共享,也需要这么一个数据库服务器软件,否则难以处理.

[4] 资源优化中心服务器, 很多站长都忽略了,因为根本没有见过这玩意,其实这才是P2P点播系统的精髓所在,但是一般的点播系统根本不会告诉你还要写这么个东西,因为有些点播系统根本无法统一调优, 这个服务器软件的作用是随时监测 用户端的请求 + 服务器端的负载状态 , 防止出现某些站的子服务器饿死,某些子站撑死,尽量快速优化客户的播放请求,也就是把用户的请求尽可能的转发到离客户最近[网络条件最好负载轻或者正在点播同一资源]的服务器上, 正是关键中的关键, 毕竟P2P加速是有限的, 在目前的网络条件下,主要还是靠大量服务器做种输出.

[5] 缓冲服务器,这是由资源优化中心服务器自动控制的子服务器,如果没有中心服务器,也不会有这套软件,同样,站长们基本都没有考虑过还有这么个玩意,这服务器的作用是,由中心服务器负责调度,当发现某个资源种源不足而点播用户较多时,自动加入下载并协助发布,或者将某些热门资源推送到离客户最近[网络最优]的点, 其实目前常见的某下载工具提供给用户做挂机的软件,并奖励水晶之类的可兑换物体的原理,和这个缓冲服务器是一样的,把这个服务器软件加个界面发布给用户,并提供奖励,就变成了大众化的缓冲加速了,这也是将来的趋势,毕竟那种后台强制共享会引发太多的反感.

其他服务器监测之类的就不说了,主要就是5个大部分,而目前站长实际能到手的其实只有3个部分.

那么做个计算好了 , 全部从头开发

P2P传输模块, 大约需要1个资深程序员5个月时间.

模块1 , 从头开发协议什么的,至少1个老程序员5个月时间,才能基本稳定

模块2 , 也是从头开发, 大约1个老程序员3个月时间.

模块3 , 如果从头开发, 这个简单点, 大约1个老程序员 2个月时间

模块4 ,如果从头开发, 因为要做的接口和调度优化算法比较多, 大约1个老程序员 5个月时间 , 后续需要一直更新调整,估计到1年时间

模块5, 这个接口比较简单, 大约1个老程序员2个月时间.

现在我们来通算一下 5(p2p)+ 5 + 3 + 2 +5 +2 =22个月 1个资深程序员时间, 成本基本就是这样

然后整个系统组网测试大约是1个月时间, 其他的分布式服务器资源,压力测试硬件等等,

伙伴们看了以后是不是后背发凉? 感情要这么多模块组合才能做出一套P2P点播系统啊.

小编团队为了减免二次开发，节省成本，已开发完成了成熟的产品模块，已在多个平台测试运营，欢迎交流！