关于P2P下载的思考

关于P2P下载的思考

1、使用多路复用或者异步I/O模型，这本是服务器段常用的技术，但在P2P应用，每台机器既是服务器，又是客户端，共享了一个十分受欢迎的文件，可能会有很多希望连接者，或者你下载一个受欢迎文件时，可能搜索到数百上千的Peer，此时就很有必要采用多路复用或者异步I/O技术，降低应用程序所占用的资源。

2、支持传统的协议，包括HTTP和FTP，其实这两种技术能够和P2P网络集成，其中一种办法就是，在提供下载地址的同时提供一个种子文件下载，例如服务器中提供了ABC.rar文件，同时提供一个ABC.rar.md5文件允许下载，这样P2P下载工具下载时，通过md5在P2P网络中搜索更多的资源，这样客户能够获得更好的速度，服务器端也可能降低下载的网络流量。

3、流行的P2P网络协议支持，包括BT和emule，这两种都是公开协议了，都有开源的实现，可以参考并重写，要支持并不困难。

4、健壮性。如同emule一样，将文件分块（piece）的同时，把每一块摘要一个piece_ID，将所有的piece_ID再摘要成一个总的ID，成为AICH。其实这也是一种很简单的技术，实现起来并不困难，做法可以多种多样。

5、对大型局域网有特别支持。现实中，存在很多大型的局域网，局域网之间的拥有高速的带宽。对局域网的特别支持办法也有很多的，例如，类似BT那样，在局域网里建立一个Tracker Server。若是基于JXTA，可以在局域网里部署聚合点（Rendezvous）

6、支持P2P目录共享，现在流行的P2P下载工具，都不支持以目录为单位实现P2P共享和下载。其实支持P2P目录共享也不困难，在提供共享时，提供一个目录结构信息就可以了。目录结构信息dir_info可以这样记录：子文件或子目录路径 偏移量 长度。当然把目录压缩然后提供下载也是可以的，不过这样会浪费共享者的磁盘空间。目录共享，要考虑共享之后文件进行修改，添加新文件等事情，使用dir_info能够更好解决这种问题。

7、关于通告。一个P2P共享资源（包括文件和目录），应该包括三个ID：content_id、aich_id、dir_info_id。其中content_id是整个资源的摘要，aich_id是每块id进行摘要产生的id，dir_info_id是dir_info的摘要id。
content_id可用资源搜索，建议采用MD5摘要产生，因为现在很多网上提供下载的文件，都提供一个.md5后缀的校验文件。
aich_id用于校验和智能恢复
dir_info_id。如果计算content_id时，dir_info独立计算，则需要提供dir_info_id，用于校验dir_info。理论上dir_info可以作为content的一部分，但是我觉得dir_info独立计算会带来很多好处。

8、关于传输。资源的传输，应该包括三部分，hashset的传输、dir_info的传输、内容数据的传输。内容传输是分块传输的，我觉得采用BT的默认值256K一块挺好的。每一块(piece)摘要计算一个piece_id，所有的piece_id放在一起，就是一个hashset，hashset这个名字不大好，不直观，但既然emule协议是这样会说，我也这样说好了。dir_info是可选的，文件共享不带dir_info。

9、P2P下载技术的应用范围应该扩展，程序的安装更新都应该加入P2P的支持，将会大大提高程序的用户体验。

10、P2P的平台应该具备良好的扩展性。当我们构建起一个庞大的P2P平台时，不单单只是在其上共享文件，有很多应用可以部署在其上，包括现在很流行的P2P视频，分布式计算等等。即时通讯也是可以构建在P2P网络上的。面对众多的应用需求，我们需要一个具备良好扩展性的协议，不应该像BT和emule那样，除了下载，别无它用。可能基于JXTA是一种较好的选择。

11、安全。P2P网络应该支持安全特性，一些团体，一些企业，需要限定范围内共享资源。例如NASA的卫星数据共享项目SAXTA，采用JXTA，就是因为JXTA支持安全特性。我想很多的P2P应用场景，都需要安全，例如，企业只希望内部员工之间实现P2P资源共享等等。