过去的九个月以来，您必然对 peer-to-peer （P2P，对等网络计算）有所耳闻。在大多数人眼中，P2P 仅仅是一种局限于文件共享的应用，或是由互联网介入给计算方法带来的新发展。这种错误的印象很大程度上是由那些极端的 P2P 支持者造成的。
事实上，P2P 计算是非常重要的。它成功地将许多被忽略的有用技术拉回到大家注视的焦点。掌握如何将 P2P 计算应用到更广阔的技术领域是很有帮助的。当然，通过一些实际的 P2P 代码来学习也是必须的，所以本文也会给出一些用 Java 语言编写的代码例子。
下面将具体阐述 P2P 的有关知识。为了避免陷入其他一些不太重要的周边细节讨论，本文将主要集中讨论以下几个方面：
在许多流行的 P2P 应用中，不可避免地要涉及到合法、隐私安全、控制以及版权等问题。尽管这些方面都是非常有趣的课题，却不应该过分地分散掉我们讨论 P2P 技术的注意力。因此通常情况下本文不会涉及这些课题，除非某个专门的应用例子必须解决它们。总而言之，我们希望能够将精力集中在技术本身，主要包括内容和资源的管理、信赖和安全、属主和权限、通讯模型、分布式计算、以及搜索和查询等。至于 P2P 技术所涉及的社会、政治和合法性等问题则基本上略过不谈。
发展历史
P2P 应用最初出现时和现在并不相同。事实上可以认为它是若干不同技术以及流行趋势的产物。下面是两个导致 P2P 技术发展最重要的趋势：
首先是某些新技术与软件工程结合，形成了一种将工作分散的趋势。P2P 计算正是这种分散工作趋势的自然结果。
其次，从工程的角度看来，在企业应用集成等因素的驱动下，过去十年渐渐形成一种从集中的单机系统转向分布式系统的趋势。在集中式的应用中进行控制是相对容易的，这一点在一定程度上抑制了分布式潮流的发展。然而随着互联网的发展，以及 B2B 商务交易方式的日益流行，全面的分布式计算也就成为一种商业需求。
对功能强大的网络计算机的需求以及昂贵的带宽开销，是对这种趋势影响最大的两个因素。为了提高效率，P2P 计算由许多互相连接的同位体 (peer) 组成。
这两种趋势导致了 P2P 应用技术研究的迅速发展。
除了技术方面之外的社会因素也是一个重要原因。毫无疑问，人们现在对 P2P 计算技术的热切关注起源于 Napster, Scour, Gnutella, 以及这些家族的其他成员产品。这些产品提供了所谓的 "killer apps" 功能，能够将 P2P 技术中的一部分下放到客户端用户的手中。正是这种第一手的体验，使得人们越来越关注 P2P 技术的强大功能。
然而必须指出的是，最初的 P2P 应用大约产生于20年前，并且其中的许多至今仍然被使用。尽管这些早期应用的核心就是 P2P，但由于大多数的使用者并未感觉或接触到，因此通常并不认为它们是 P2P 技术。
早期的尝试
P2P 计算并非一种全新的技术。虽然 P2P 这个术语是现在才发明的，但 P2P 本身的基本技术的存在时间却至少和 USENET、FidoNet 这两种非常成功的分布式对等网络技术一样长，甚至更长些（因此笔者建议读者朋友去尝试这样一个挑战——寻造最早的 P2P 应用，尤其是那些现今仍在使用的应用）。关键在于，在最初的 P2P 应用出现时，许多使用该技术的人们甚至不会使用计算机。
USENET 产生于 1979 年，是一种分布式系统，能够为各个地方提供新闻组（笔者最喜欢的是 rec.arts.int-fiction 和 rec.games.int-fiction）。USENET 最早的雏形由是两名研究生 Tom Truscott 和 Jim Ellis 实现的。当时并没有任何类似于互联网上“随选”信息的概念，文件只能通过电话线批量传送，且常常选在长途费用比较低的夜间进行。因此，当时的 USENET 若采用集中式的控制管理方法将效率低下，自然而然地就提出了一种分散、分布式的管理方法。这种分布的结构一直沿用到今天。
早期 P2P 应用另一个杰出的代表则是 FidoNet。它和 USENET 类似，也是一个分散、分布的信息交换系统。Tom Jennings 于 1984 年创建了 FidoNet 系统，来让不同 BBS 系统中的用户们互相交换信息。这种符合人们需要的技术，迅速成长起来，并一直沿用到今天。
USENET 和 FidoNet 都是值得探究的系统，因为它们在多年前就遇到并解决了许多当今 P2P 技术所面临的同样问题，同时也还存在着安全性以及其他一些问题。为了开发成功的 P2P 计算系统，首先必须了解这些 P2P 技术的发展历史。
技术前景
前面我们已经浏览了一遍 P2P 的发展历史，下面可以做一些文字游戏。
几乎所有人都会同意 “P2P 计算是分布计算的一个子集”这种说法。而且大多数人也都会认为“并非所有的分布式计算都是 P2P 计算。"peer-to-peer" 这个名字意味着各个 peer 之间的关系是平等的，并且它们之间的联系是直接的。
P2P 网络中含有许多能够互相通讯的 peer，每个 peer 都有专门的用途。通常情况下，网络中 peer 的数目是非常大的，但用途却只有若干种。这就是 P2P 应用之所以能大量并行运行的重要原因。众所周知的 Gnutella 网络就是一个最好的例子，它包含了大量本质上相同的 peer。P2P 技术中最有趣的地方就在于这些对等 peer 之间的联系，其次则是它们自身。
在很大程度上，P2P 计算与那些分布计算所面临的问题是重叠的——调整并监控网络中独立节点的动作，并确保鲁棒性、以及节点间的可靠通讯。但并非所有的分布计算都是 P2P 计算。比如象 SETI@home 或 distributed.net 中不同的项目，这些分布计算几乎没有考虑网络节点中的对等交互，因此并不能认为是真正意义上的 P2P 应用。然而由于分布计算和 P2P 面临很多相同的问题，这就值得我们了解一些分布计算方面的内容。对于这类不能算是 P2P 技术的分布计算，笔者建议用“面向同位体”的应用（peer-oriented）来命名。
最简单的 peer 以及它存在的问题
使用 Java 语言编写一个最基本的 P2P 应用是非常容易的，这里笔者给出一个简单的例子，以供读者参考。给出这个例子的另一目的则在于表明，在网络中传送文件和消息是很方便的。然而若要为 P2P 应用建立一个鲁棒性很好的平台则很困难。这个 P2P 例子中缺少了许多应有的重要特性。其中，例如安全性等特性也是当今许多流行的 P2P 应用所缺乏的。另外一些特性（例如消息路由和分布查询等）则在某些应用中得到了实现，例如 Gnutella 就能够支持简单的消息路由以及分布查询。
图 1 中显示了一个典型 P2P 应用的系统框图。为了支持文件共享，这个 P2P 系统只负责与抽象的资源进行交互，而具体资源则从 Resource 接口中获得。这些具体资源可以是任何可定位的信息，包括文件系统、数据库、词典或是一个电话本。
图 1. P2P 应用的主体设计框图
MessageServer 类是这个 P2P 应用的核心。它能够与其他的对等网络获得联系，并将消息转发到合适的地方。
该类的具体代码在文件 p2p.jar 中（可以在 资料 部分下载此文件）。读者可以试着在命令行环境下，输入 java -jar p2p.jar，就能够运行这个简单的 P2P 应用程序。
这个程序会从它所在的目录中寻找名为 p2p.properties 的属性文件。在属性文件中可以定义要下载的资源以及它所知道的同位体信息。您所下载的 jar 文件中还含有一个属性文件的样本，可以对它进一步修改。
如图 2 所示，用户可以通过简单的命令行界面与该 P2P 程序交互。如果已选择了某个 peer 或是正在访问某些远程资源，则该程序会将相关的信息显示出来。
图 2. 程序的初始运行界面
任何时候，用户只要在提示符后面输入一个问号（?），屏幕上就会显示出一系列选项（如图 3 所示）。如果用户还没有选择 peer，输入问号时，就会显示出该程序的所有已知的 peer；否则则显示已选定 peer 能够访问到的资源。只要在提示符后面输入某个 peer 或资源的名字，就能够选定它们。
图 3. 显示 peer 和资源列表
在图 3 中，用户选择了名为 "guppy" 的 peer，然后显示 guppy 能够获得的资源。在选定 peer 和资源之后，用户就能够访问并控制该资源（如图 4）。如果选定的是一个文件系统资源，那么对该资源对象的访问就意味着从远程 peer 将该对象拷贝到本地 peer 中。
图 4. 列出可控制的资源对象
只要输入两个点（..），用户就可以随时取消对某个资源或 peer 的选择。
图 5. 取消选择
结论
真正的 P2P 应用程序显然要比本文中这个简单的应用程序复杂得多。它至少还需要扩展以下几个方面的功能：足够的安全性（包括验证以及授权等机制）、可靠的消息路由和传送、内容和资源的管理、分布查询以及命名。在以后的章节中，笔者还会提出一些的具体例子和工作代码，来进一步讨论这些功能的实现。
资料
Peer-to-Peer working group（对等网络研究小组） 。该小组是一个致力于研究 P2P 计算底层标准的联盟。 在 USENET 历史 中可以浏览 USENET 发展的概况。 在 FidoNet 历史中可以看到 FidoNet 方面的相关信息以及源码。 O'Reilly 的 OpenP2P.com 站点，上面含有大量关于 P2P 计算方面的新闻以及技术。 下载 p2p.jar 文件（对等网络的简单实现代码）。关于作者
Todd Sundsted，从桌面 PC 流行起就开始从事编程工作。起初兴趣主要集中在使用 C++ 语言编写分布式程序，后来意识到 Java 语言在这方面的显著优势，从而转向采用 Java 编写分布式程序。除了编程之外，Todd 还是 PointFire 有限公司的首席工程师以及创办人之一。您可以通过 [email protected] 与 Todd 联系。
本文地址：http://com.8s8s.com/it/it12799.htm