这个月，我将不在高层次领域（高达 1000 英尺）继续讨论，也不解决安全性问题，相反，我将在低层次领域（50 英尺）讨论应用程序框架。

我真诚地希望这个转变将比现实生活中经常遇到的转变更令人愉快。

安装与执行
让我们从安装的具体细节开始。我略微更改了启动 P2P 应用程序的过程，因为在上个月，一些读者在启动应用程序时遇到了问题。

在可以运行 P2P 应用程序之前，必须下载两个 jar 文件 -- p2p.jar 和 spp.jar -- 以及配置文件 app.properties（请参阅参考资料）。p2p.jar 文件包含 P2P 应用程序自身的类文件。spp.jar 文件包含 P2P 应用程序所使用的消息传递库的类文件。

下载这些文件之后，将这两个 jar 文件和包含配置文件的目录添加到类路径中。

如果您正在运行 Windows，并且已经将这两个 jar 文件和配置文件下载到 c:\p2p 目录，则可以如下设置类路径：

set CLASSPATH=c:\p2p\p2p.jar;c:\p2p\spp.jar;c:\p2p

如果您正在运行 Linux、Solaris 或某个合适的 UNIX 变体，并且已经将这两个 jar 文件和配置文件下载到 /home/foo/p2p 目录，可如下设置类路径：

export CLASSPATH=/home/foo/p2p/p2p.jar:/home/foo/p2p/spp.jar:/home/foo/p2p

（以上命令假设您正在运行 BASH 来作为命令 shell）。我将如何在其它流行的 shell（如 CSH）中设置环境变量的问题留给您自己去考虑。

一旦设置了类路径，就可以用以下命令启动应用程序：

java com.etcee.app.ki.Main

P2P 应用程序将显示一个别致的信息性标志和一个命令提示来欢迎您。

最后再说一遍：我的 P2P 应用程序一定需要 Java 2 平台。

配置文件
前几步将启动并运行 P2P 应用程序，但是，在能够很好地使用它之前，必须编辑配置文件。配置文件定义 P2P 应用程序使用的端口、控制的资源以及识别的伙伴。清单 1 演示了每一个定义。

清单 1. 示例配置文件

com.etcee.app.ki.port=7777com.etcee.app.ki.resource.0.name=sharecom.etcee.app.ki.resource.0.class=com.etcee.app.ki.resource.file.FileResourcecom.etcee.app.ki.resource.0.arg0=/home/foo/sharecom.etcee.app.ki.resource.1.name=tmpcom.etcee.app.ki.resource.1.class=com.etcee.app.ki.resource.file.FileResourcecom.etcee.app.ki.resource.1.arg0=/tmpcom.etcee.app.ki.peer.0=bass:7777com.etcee.app.ki.peer.1=salmon:7777com.etcee.app.ki.peer.2=perch:7777com.etcee.app.ki.peer.3=guppy:7777

第一部分由一行组成，它定义了 P2P 应用程序用来接收其它伙伴连接请求的端口。最好不要改变这行。

第二部分定义 P2P 应用程序管理的资源。您可能需要编辑这部分。清单 1 定义了两个资源：share 和 tmp。从应用程序的观点来看，资源只是实现 Resource 接口的类的实例，我们将马上讲到这点。资源定义一般具有以下基本形式：

清单 2. 资源定义

com.etcee.app.ki.resource.0.name=<name>com.etcee.app.ki.resource.0.class=<implementation class>com.etcee.app.ki.resource.0.arg0=<initialization argument>com.etcee.app.ki.resource.0.arg1=<initialization argument>..

name 是给予资源的名称，它用来生成人们可读的输出。class 是 Java 类的名称，可以将其初始化以创建资源。P2P 应用程序在运行期间动态装入这个类并将其初始化。在其初始化期间，argN 自变量被传递到新初始化的资源。例如，FileResource 类使用这些自变量定义目录来为文件提供服务。您需要编辑目录自变量以指向您机器上的某个目录。

第三部分定义 P2P 应用程序识别的伙伴。每一行都包含伙伴的名称（或 IP 地址）和伙伴的端口。用这种方式定义伙伴显然不是可伸缩的解决方案。在以后的文章中，我们将看一种更好的解决方案。

代码
除了对等通信采用的 SPP（简单点到点）包之外，P2P 应用程序不包含很多类。首先，我们先仔细查看最重要的类，最后再看一下 SPP 通信包。

资源
P2P 应用程序的主要组件是资源。事实上，P2P 应用程序只是允许和控制对已发布资源的远程访问。资源可以是任何可寻址的事物 -- 文件系统、电话簿、数据库和目录。每个资源都管理零个或多个适当类型的项（文件系统资源管理文件，电话簿资源管理电话号码）。

为演示如何实现资源，我创建了一个简单的文件系统资源类 FileResource，如清单 3 所示。这个文件系统资源管理零个或多个文件。

清单 3. Resource 接口

publicinterface Resource{// The initialize() method requires a TTDFactory instance// (which the factory uses to create the TTDItem instances// it returns from the select() method in response to a// query) and a String array (which contains the arguments// from the configuration file).publicvoidinitialize(TTDFactory ttdfactory, String [] arstring)throws ResourceException;// The select() method requires a String instance that// defines the selection criteria.  It returns an array// of TTDItems, one for each entry that matches the// selection criteria.publicTTDItem []select(String stringSelector)throws ResourceException;}

Resource 接口定义资源的结构和行为。该接口还定义允许在资源上执行的操作。目前的操作列表包括 select。以后的实现还将包括 insert 和 delete。

select() 方法将一个定义选择标准的字符串作为参数。该方法返回有关所有与选择标准匹配的资源项的信息。按照当前 P2P 应用程序中的文件系统资源所实现的方式，选择字符串既可以直接命名一项，也可以包含通配符 "*"，当直接命名一项时，资源将返回该项本身及其相关元数据；当包含通配符时，资源将只返回它所管理的所有项的元数据。还可以使用更复杂的查询语言，但这不在本文讨论范围之内。

Shell
Shell 类只是一个允许用户浏览本地和远程资源的非常简单的命令行用户接口。它使用 PeerReference、ResourceReference 和 ItemReference 类向其它伙伴发送请求，但它本身只分析用户输入。

为了从请求伙伴的角度更好地理解通信的工作原理，让我们看一下清单 4 中显示的 PeerReference 类的一部分。

因为我在上个月详细描述了通过 shell 进行的用户交互，所以不再这里重述。在第一次启动 P2P 应用程序之前，请停一下并使自己重新熟悉它的操作。

通信
P2P 所做的全部就是伙伴间的通信。那些对原始得令人难以置信的 Napster 协议熟悉的读者应该理解我为什么选择高级一些的协议。我在这里只略微提及 SPP。在以后有关 P2P 通信的文章中，我将详细描述它。

SPP 将消息建模成一个帧序列，如图 1 所示。

图 1. 消息

消息中的每一帧都有一个类型（由 MIME 类型指明）和一个主体。帧中的头是可选的，它用来描述主体中的数据。

构成完整而正确的消息的序列中的帧类型取决于应用程序。一般来讲，一条消息由一个控制帧和其后零个或多个数据帧组成。数据帧包含控制帧所引用的数据。我们的 P2P 应用程序就采用这种模式。

消息出现在请求／响应对中。一个伙伴向另一个伙伴发送请求。那个伙伴再将响应发回给第一个伙伴。

请求消息中的控制帧是命令帧。它包含命令和为该命令提供的所有参数。如果有任何其它帧存在，则这些帧包含命令帧所需的信息。

响应消息中的控制帧是状态帧。它包含状态（正确或错误）。如果有任何其它帧存在，则这些帧包含状态帧所引用的信息。如果向文件系统资源发出请求，则该信息将包含所选文件的内容。

多帧消息模式的优点在于：它允许在通信应用程序之间交换内容丰富的消息。SPP 在很多方面都类似于 BXXP（请参阅参考资料）。

结束语
完全理解了框架之后，我们就可以在下个月继续讨论 P2P 安全性了。我们还将在 P2P 应用程序中集成安全性支持。