温少的日志

上一篇博客写了我一些关于P2P下载以及平台的思考，有这样的思考，是因为我正在做一件这样的事情。

我介绍一下我正在做的事情吧：

1、基于JXTA，我崇拜Bill Joy，学习JXTA就是因为我崇拜他，之后觉得这个技术很棒。但是JXTA存在一些用户不友好的地方，包括JXTA的ConfigDialog和DialogAuthenticator是十分用户不友好的，我重写了这些部分。虽然是一些无关痛痒的地方，但是可以改变用户体验，提高用户友好性。

2、简单的插件机制，我做了一个简单的插件系统，Application启动之后挨个装载服务，UI也是服务之一，UI也是基于插件的，在微内核框架流行的今天，使用一个简单的插件机制似乎不是太好，等过一段时间之后考虑使用osgi替代之。

3、提供了两个功能，聊天和文件共享下载。这两个功能分别表现为两个JXTA的Service。

4、聊天功能。目前还比较简单，只实现了不带格式的文本聊天，但是我随后会加入带格式的文本聊天，也将会加入类似腾讯QQ那样的贴图支持，自定义表情支持，腾讯QQ的实现很巧妙，但并不困难。四月初的版本就有可能实现之。

5、共享和下载。目前实现了文件和文件夹的共享。其中包括了高级智能错误检测（AICH）等。传输协议参考了BT和emule的协议。在界面中还实现对DragAndDrop支持，从Windows Explore中拖一个文件到目录共享的面板，即开始共享该文件。

6、存储信息采用apache的Derby数据库。我很喜欢Berkeley DB，Berkely DB高效简洁，但是License不开放。我最终还是采用Derby了，采用Derby将会带来一系列好处，SQL支持、JDBC支持等等，License无限制等等。扩展的应用基于其上也十分方便。由于我曾经开发过多数据库支持引擎KSQL，在KSQL上增加支持Derby的翻译是很容易的事情。如此一来，可能存储引擎部分，将有可能扩展到KSQL目前所支持的多种数据库，包括严格测试过的Oracle、DB2、MS SQL Server，还有经过简单测试支持Sybase、PostgreSQL、MySQL。

7、最近的JXTA Java SE 2.5版本，使用了nio来管理连接，也就说，使用了多路复用的技术，使得每个Peer创建大量连接成为可能，例如Windows下默认最大的多路复用支持1024个连接。而Linux下，java nio是使用epoll实现的，并发性能将更好，这对于聚合点来说很重要。普通的Peer部署在Linux下可能较少，但是聚合点部署在Linux完全是可能的。

8、使用Swing做界面，使用Java 6 SE的Swing，做了系统托盘Tray的支持等等。由于Swing的UI设计工具很不稳定，最终完全手工编写UI部分代码，虽然辛苦，但是代码简洁，不同UI Designer生成的那样。

9、我期望4月初发布一个版本，提供一个基本可用的版本。

10、我是从1月初开始学习JXTA的，到现在还不满3个月，其中还包括过年回家休息等等，玩游戏沉迷等等，但总的来说，我对这个学习速度很满意。不过其中感觉最爽的是，在这个过程中，编码时，基本纯键盘操作，不用鼠标，如行云流水一边，十分流畅，工作效率高，人也舒服。

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资源共享等等。