P2P应用模型设计

    此文章的题目来自于当下的两哥之争，本意有调侃之意，但是用在本文，却无此意，我以十分真诚并且后知后觉的态度认定，p2p是未来的主要计算模型。尤其是在视频音频领域，但是将来，p2p一定会拓展到普通的计算上。

    要解释清楚这个问题，我们得从当下最流行的音频视频p2p软件聊起。先来说说较为简单的一个音频p2p软件，酷狗。

    酷狗的原型应该是来自于一个国外的公司，名字我已忘记，那家公司也是通过mp3的p2p下载作为主要业务，不过可惜的是在美国mp3因为版权问题非常严重，所以那家公司的最终结局只有一个，就是关门。

    但是在中国就不一样了，版权问题没有这么严重，或者说相当的不严重，所以酷狗活得很好。这就是国情啊（理论上来讲，酷狗应该也有一些版权问题，可能跟版权商有合作关系，不过大多数的音频应该没有版权问题，这种情况和视频网站是类似的）。

    下面让我们来看看酷狗的技术实现。以下都是ahuaxuan的猜测，供大家讨论，未必完全正确，也未必完全错误，拿出来和大家探讨。

    酷狗应该是采用中心的目录服务器结构来实现p2p的功能，也就是说，所有的音频文件的基本信息都会注册到酷狗的中心目录服务器上，那么酷狗的客户端需要下载某个视频的时候，则从中心目录服务器上查找，找到相信的音频信息，每个音频信息都会对应一堆地址，这些地址是其他的拥有该音频的客户端ip。让我们用一张图来描述一下这个问题：


这样我们就可以虚拟一个流程出来：
1．1号客户端请求中心目录下载服务器，要求下载“”。
2.  中心目录服务器通过搜索引擎分词，查询之后，得到一堆id。
3.  中心目录服务器根据id查找id对应的ip。显然一个id拥有多个ip，是1:n的关系。
    （很不巧，这首歌2，3号客户机上都有， 当然这里并不是应该返回所有的ip地址，而是应选择最短路径的地址返回。让我们来怀念一下dijikstra。
4.  中心目录服务器返回音频文件的ip列表。
5.  1号客户机得到两个ip地址，然后分别2号机请求音频的第一段，从3号机请求音频的第二段。即多地址多线程分段下载。
6.  1号机下载完成之后通知中心目录服务器，这样中心目录服务器关于这个视频又多了一个ip地址供其他客户端下载。


这个应该是最概要的流程，接着可以在这个流程上细化。

从上图我们可以看到，任何一个客户机既是client，又是server。作为client，它从其他server上下载数据，作为server，它提供数据给其他client下载。

    所以当我们开着酷狗听歌的时候，其实你的机器就变成了下载服务器了，同样，如果你用的是迅雷，而且一直不把迅雷关掉，那么你的机器就成为专职的下载服务器了。

    看到这里，我们有理由相信，如果掌握了下列技术，做一个酷狗不是什么难事，括号后面是ahuaxuan的选型。

1.    搜索技术(lucene)-服务器端
2.    音频管理系统(java，同时涉及到缓存和数据库系统)-服务器端
3.    客户端ui编程（最好是mfc之流）-客户端
4.    下载服务器(c，对windows的io比较熟悉)-客户端

正如前面所说，这个只是非常高层次的设计，而且对于有过大型网站系统经验的人来说，1，2点是没有问题的。然后3，4点需要对c/c++比较熟悉的人来做，当然btcomet据说是python写的。所以我也在思考python+c实现客户端的可行性。


    上面讲到的是基本的整个软件的结构体系，或者称为“架构“，在high level层面还有一个问题，就是协议的问题，客户端之间相互下载应该使用说明协议，以及客户端和服务器端的交互应该使用什么协议，目前ahuaxuan 选择的是bt协议。利用成熟的协议可以减少很多的工作量。或者电驴的协议应该也不错，不过没有深入研究过。