前言

这一阵子以来，对于点对点（ peer-to-peer，P2P ）运作技术感到兴趣的单位愈来愈多，并且不乏将P2P 技术巧妙运用而大受欢迎的公司，如Napster 以及Gnutella 等等，由于P2P 技术是另外开启了异于Web 存取模式的管道，因此其优势与潜力引起了业界相当大的兴趣。本文撰写的目的，就是要延续并拓展微软与升阳在「伺服架构」部份的比较层面，伴以目前较为热门的技术议题，引领读者接触目前最新的科技知识。

《图五 JXTA运作模型所规划的层次》

由于 P2P 的应用，是建立在点对点的资料分享上，并且期望能够透过这样的技术，建立起用于广大网路中资源分享的共用基础。因此本文将会以 P2P 的技术概念为出发点，解释 P2P 架构几种可能的运作模式，接着笔者便会针对微软与升阳在 P2P 方面所努力的成果做一介绍。借着这种形式的介绍，可以让读者更容易了解两大架构中对 P2P 所做的支援与定义，进而更了解如何针对这两种架构，进行 P2P 应用的研发。

P2P 简介

自从 Web 浏览成为网际网路上最主要的活动之后，人们无时无刻不在想着如何能够运用更创新的技术，来善加利用网际网路上的资源。在多方的尝试之中，分散式计算的应用算是其中较受嘱目的一环。举例来说，SETI@home 就是利用全球上百万的使用者，共同贡献出部分的电脑运算能力，来做合作分析的工作。此外，即时讯息传递也是运用任两点端来进行即时的资讯传播。而在这些应用之外，所谓的P2P 运算，就是试图提供网际网路使用者直接相互分享并搜寻特定的网路资源，如Napster、Gnutella、Freenet、以及Scour 等等，并且这样的运作模式，通常都不需要集中式的伺服主机。而当愈来愈多的 P2P 应用出现之后，就自然形成了一个新的领域。这些领域拥有自己的平台，执行单一的功能（如音乐、档案的传递等等），但是却无法与其他运作模式类似的平台进行资料沟通。

微软的.NET 平台，提供了一种具多样性的架构与支援，用以建立许多具有不同用途的应用程式而其中当然也包含了对P2P 应用的支援，其中.NET 架构特色的支援如（表一）所示：

而反观升阳的Java 阵营，正努力的推动JXTA 计划，用来定义一个建立分散式服务与应用的共同平台，目的在使应用程式开发者能够更专注于应用程式本身逻辑的开发，同时给予快速建立P2P 分散式计算软体的能力。

P2P 的应用

那么，什么是 P2P 应用呢？其实我们都可以理解到，不论是何种应用程式，大都会有一个共同的要点，那就是资料传输。当程式与程式之间能够透过某种管道进行资源的分享与交换时，应用程式的价值便大大地提高。

目前最常见的网路通讯模式为主从式的运算模型（ client-server model ），客户端知道如何对伺服端发出请求，而伺服端也知道如何对客户端做出回应。而目前我们最常见的主从式运算模型，就是 Web 浏览器与 Web 伺服器之间的沟通。这种沟通模式，是由许多个浏览器送出存取请求至 Web 伺服器，而 Web 伺服器的工作则是持续的等待外界所传入的请求，同时对这些请求送出相关资料当做回应。在这样的模型中，Web 伺服器并不能与浏览器主动接触，也就是说，所有的沟通对话，都是由客户端开始发生。相对来说，一个 P2P 的应用程式就不是以传统主从式的模型来运作，而是每个端点（ peer ）都会同时具有客户端与伺服器两种角色。也就是说，在某端点对外送出请求的同时，它也具备了回应其它端点请求的能力。通常一个典型的 P2P 应用程式会有以下几个重要的特色。

1.搜寻/发掘其他端点的能力( Discovery )

P2P 端点必须要有能力找到其他愿意分享资讯的端点。以往这样的工作都是由向中央伺服器登记与存取上线端点的资料所完成（如 ICQ 等），但这并不是唯一的方式。仍有许多网路上广播（ broadcasting ）与发觉（ discovery ）演算法可以完成相同功能的运作。

2.查询其他端点的资料内容（ Query ）

一旦找到其他端点之后，（ P2P ）应用程式便可以对它发出查询资料内容（ content ）的请求。在此同时，P2P 应用程式也常会自动发出其他网路请求，以便利程式自身的运作需求。

3.与其他端点共享资料内容( Sharing )

如前所述，P2P 应用程式也可以具有伺服功能，因此它也可以与其他端点分享资料内容。

P2P 的运作模式

接下来，我们就来探讨一下，在这几种不同的 P2P 运作模式下，各会有什么样的特色。目前常见的P2P 运作模型有四类，分别是纯粹的「点对点模式」，具有发觉功能伺服器的模式，具有发觉与查询功能伺服器的模式，以及具有「发觉」、「查询」以及「资料内容功能伺服器」的模式。以下就是这四种模式的简要介绍：

1.纯粹的点对点模式（ Pure P2P model ）

所谓纯粹的 P2P 模式，就是动态地去寻找网路上的其他端点。同时也动态地分享与交换各自所拥有的资料内容，如（图一）所示。这种模式的好处，是在于这样的运作组合并不需要仰赖任何的伺服器，而这类伺服器的用途是在于登录同类型的端点。但是这种模式也有其缺点，就是在缺乏集中式伺服器管理的情形下，能够寻找到的其他端点数目会相对较少，因此限制了应用程式所能够延展的存取范围。在这样的状况中，端点可以透过自身预设的组态或是透过网路广播的方式来和其他端点取得联系。

《图一 纯粹的点对点运作模式》

2.具有发觉功能伺服器的模式（ P2P with Simple Discovery Server ）

在这种模式下，所有发觉端点的动作，都是透过一个集中式的伺服器所提供的查询服务来完成，如（图二）所示。在这种模式下，P2P 应用程式会在初始化时通知伺服器自己已经存在的讯息，以方便其他端点的寻找与发觉。而最后资料内容的下载则是经由两方端点的沟通，并不牵涉到集中式的伺服器。在大多数的状况下，这种运作组合会有较好的扩充规模。但其限制是在于集中式伺服器的数量与取得难度。此外，由于这种模式可以让两个距离甚远的端点取得连系。因此远距离网路传输负担将会是影响品质的重要因素。

《图二 具有发觉功能服务器的运作模式》

3.发觉与查询功能伺服器的模式（ P2P with Discovery and Lookup Server ）

这种模式和上一个模式相当类似，只是集中式伺服器将会多了一项任务，也就是资料内容的查询服务。在这种情形下，P2P应用程式不止是要将自己登录在集中式的伺服器上，同时也会定期上载自身所欲分享的资料内容相关资讯。

当有某个端点希望寻找某种资料内容时，它就会对集中式伺服器发出查询的请求，接着才会依据查询结果来与真正提供的端点做连系沟通。一般而言，这种模式会比上一种模式还要具有扩充性，因为集中式的查询可以明显减少网路上所会出现的查询请求数量。当然了，这样省下的网路负担代价，自然就会转嫁到集中式的伺服器上。

4.发觉、查询以及资料内容功能伺服器的模式（ P2P with Discovery, Lookup, and Content Server ）

这种模式下各个端点将会把自己所欲分享的资料内容，在初始化时上载到伺服器上，请参考（图三）。这种做法就是一种演化成主从式模型的运作方式。每个端点不论是在登录工作、资料查询、以及资料内容的存取上，都会与集中式伺服器做连系。而且「只」与伺服器联系。这种做法的问题是在于一旦 P2P 应用程式将自己的资料内容上载之后。伺服器马上就成了容易产生瓶颈的所在。因此，将 P2P 模式转成主从式运作模型，将是 P2P 美意上的一种浪费。

《图三 发觉、查询以及数据内容功能服务器的模式》

在介绍完各种 P2P 运作模式之后，我们将探讨微软与升阳两大阵营。在这两大阵营所设计的应用伺服架构下，又该如何对 P2P 这样的运作模式，给予基本技术上的支援。

微软的 P2P 支援方案

由于微软所推广的是其引以为傲的 .NET 架构，因此，在 P2P 应用的设计上，.NET 也提供了许多开发上的选择。请注意，程式开发者在设计 P2P 应用时所做的决策，将会大大影响其使用者所会付出的网路运算代价。在 .NET 架构下，设计 P2P 应用将会有四种应用型态可供选择，以下我们就逐一的检视这些型态。

1.Web 服务型态（ Web Services ）

这是在.NET架构中System.Web.Services 层次下的定义的型态。在这种型态下，举凡是登录、发觉、以及资料内容的服务，.NET 都提供了良好的支援。其中所定义的 Web 服务，让开发者可以轻易地建立起具有等待请求、处理请求、以及送回​​标的资料物件的 P2P 应用。

2.Windows Forms 型态

这是在.NET 架构中 System.WinForms 层次下所定义的型态。在 .NET 架构中，Windows Forms 提供了一组丰富的图型使用者介面元件，这些元件可以让 P2P 应用的互动性更加丰富与有趣。因此很适合用在几种处理步骤上：使用者登入、请求发送、以及资料内容的分享等等。

3.Web Forms 型态

这是在.NET架构中 System.Web 层次下所定义的型态。这种型态所支援的，是提供简便的方法来产生 HTML 内容，用以回传到 P2P 应用上。当 P2P 应用初始化的同时，不但可以登记自身所愿意提供的 Web 服务，同时也可以取出集中式伺服器中最新的 HTML 资料。

4.Service Process 型态

这是在.NET架构中System.ServiceProcess 层次下所定义的型态。这里所谓的 service，其实指的就是 Windows NT 中的 service，是一种长驻形式的程序。 Service 对于 P2P 模式中的发觉伺服器而言相当有用，因为它是一个需要提供长期服务的部份。

除了提供丰富应用型态之外，.NET 架构也大幅地简化了 P2P 应用中所需的网路运作。其中包括 System.Web.Service 以及 System.Net 两个部份。因此笔者就针对这两个部分来做介绍。

System.Web.Service 层次

在 System.Web.Service 层次下的物件类别，主要是用来开发提供以及使用 Web 服务之用。而所谓 .NET 架构下的 Web 服务，就是一种建构在 SOAP（ Simple Object Access Protocol ）协定上的应用程式逻辑。 SOAP 是由 W3C 的定义用来编译及传输资料的重要协定，其中利用了 XML 为资料描述的标准，而以 HTTP 为底层的传输媒介。对使用这种Web 服务的客户端来说，并不需要对该服务所在的平台、物件模型、甚至所使用的程式语言有所认识，而只需要知道如何发送以及接收SOAP 讯息即可，而在.NET 架构下，建立一个Web 服务就如同在伺服器上建立一个网页物件类别般简单。同样地 P2P 应用程式使用 Web 服务也相当地简单，只需要呼叫一个由 Visual Studio.NET 产生的物件类别中的方法即可。至于其他的技术细节，请另行参考 .NET 平台 SDK 的技术文件。在说明了如何去开发 Web 服务的同时，将可提供外界呼叫的介面（ API ）并公开登录给 P2P 应用程式查询的情形。

在此情形下，主从式模型及 P2P 模型是以混合存在的状态出现。使用这样的混合模式有一种好处，它可以反映出主从式模型的单纯，同时又可以展现出 P2P 运算的强大。

在建立 Web 服务的步骤上，你必须先了解一个叫做 P2PService 的重要类别。这个类别定义了你可以用来呼叫使用 Web服务的方法。而除了建构的方法之外，其他的类别方法请参见（表二）。除了P2Pservice 类别之外，另外有一个PeerFile 类别，是用来储存 P2P 运算模型中有关档案的相关讯息。 PeerFile 包含了以下的类别成员：IpAddress，代表了端点的 IP 位置；Name，代表了档案的名称；Connection，代表了端点连结的型态以及速度；Size，代表档案的大小。

System.Net 层次

在 System.Net 层次下的物件类别，主要是用来支援使用各种网路协定收发资料之用。由于是使用层级式的做法，使得应用程式的开发可以自由选择所需要的层级，包括从最细小的socket 控制到最大范围的请求/回应模型，反映出了目前网际网路上各式常用的通讯方法与协定。

此外，System .NET 下的类别，也可以随着网际网路的改进而做有弹性的延伸。第一种类别方法，称为ListenForPeers。这个方法会让 P2P 应用程式进入等待请求到达的模式中，以回应任何一个端点所送达的请求。而当其他端点连结上之后，就会开始处理所欲取用的档案名称，并回传之，这便是它最主要的程式功能，而由于程式是以多执行绪（ multi-thread ）的模式运作，所以当P2P应用程式正在处理某个端点的请求时，仍然可以接受外界其他端点的连结请求。

另一种类别方法，称为DownloadToClient。这个方法就是用来连接其他端点并要求取用档案资源的部份。除了以上所提到的档案分享功能之外，P2P应用程式也可以用来当做 Web 浏览的工具，也就是说，成为一种提供 HTML 内容的支援技术。在 System.NET 下所定义的WebRequest 以及 WebResponse 两种类别，分别用来构成 Web 伺服器的主要功能。

至于在扩充性部分的问题上，不同的P2P 设计也会产生相当不同的影响。一般而言，影响 P2P 最巨的因素，便是网路频宽的多寡，同时这也是 P2P 运作最容易发生瓶颈的所在。因此，如何小心设计搜寻/发觉其他端点以及查询其他端点资料内容的方法，将可以大大左右 P2P 共同运作的最大数量，这也是目前在 P2P 技术方面亟待讨论的课题。

在看完微软在.NET 架构下对P2P 应用的支援之后，接下来我们就来看看另一个阵营－也就是升阳的Java 阵营，在P2P 应用模式的设计上，到底提供了什么样的支援技术。

升阳的 P2P 支援方案

升阳公司一直在网际网路方面，是最为积极的技术参与者之一。有鉴于 P2P 应用，可以造就更大规模的协同运作与通讯。升阳早就着手设计新一代的技术标准。由于 P2P 的运算模型，可以有效地运用并平衡各项网路资源（如计算效能、储存空间、传输频宽等等）。因此其价值自然不容忽视。

而 P2P 是由主从式模型所延伸发展( juxtaposed )而来，因此升阳在 P2P 方面的专案计画就简称为 JXTA。在 JXTA 中，升阳定义了一个开发并使用分散式服务的基础平台，其中加入运作的任何一个单位，都会被视为一个端点。而 JXTA 的目的，就是试图去提供一个完整的 P2P 运作支援，使得系统开发者可以更专注于应用程式逻辑的设计上。

在JXTA 中，定义了一个为P2P 模型所设计的开放式网路运算平台，而在JXTA平台下，有下列几项端点所应具备的功能，可被标准化：如「发觉其他端点」、 「公布自有资源」、「端点间的通讯」、「协同运作」等，这些功能可共同构成一个具有安全特性的群组。

升阳 JXTA 计画的基本网路服务

目前大多的 P2P 系统都是设计用来提供特定的网路服务（如 Napster 用来分享音乐，Gnutella 用来分享一般档案，而ATM 则是用来传输即时讯息）。由于网路服务具有多样性，同时又缺乏一个共通的基础架构。因此各家 P2P 的厂商所建立的，都是无法相容的 P2P 技术。也就因为如此，JXTA 便试图提出一个简单的 P2P 平台概念，用以提供具共通性的基本网路服务，特点如下：

1.JXTA 使用了少数的通讯协定，并且这些协定都很容易实作并整合进 P2P 的服务应用之中。因此据此开发系统的厂商，将有能力与其他厂商的应用程式做沟通。

2.JXTA 具有与程式语言无关的特性，因此它可以用许多不同的程式语言来进行实作，如 C/C++、Java、Perl 等等。也就因为如此，许多异质性的网路设备及其软体，便得以使用 JXTA 来进行沟通。

3.JXTA 具有与传输协定无关的特性，因此它可以建构在许多​​不同的传输协定之上。如TCP/IP、HTTP、蓝芽（ Bluetooth ）等等。这也意味着具有JXTA 功能的系统可以拥有扩展为使用新式网路环境或设备的能力。

升阳 JXTA 计画的优点

至于在使用 JXTA 的优点上，我们可以由几个典型的范例看出。假设目前有一个应用 P2P 的社群，其中社群成员会使用到搜寻的机制。在这种情形下，任何一个社群成员可以应用 P2P 技术，来发出查询的请求给其他有能力处理这项请求的社群成员。

《图六 JXTA运作模型所规划的层次》

我们再假设这是一个社群成员想要透过 Gnutella 系统找寻某个特定的 mp3 档案。因此，其他可提供 Gnutella 服务的端点都会各自查阅自己所可以分享的档案并回应之。因此，以 JXTA 最具一般性的运作模式来看，只要是能够提供符合Guntella 系统协定的 P2P 应用程式，都将可以提供服务。相对地，这样的 P2P 应用也不只是可以提供 Gnutella 服务，更可以提供其他不同的 P2P 应用服务。总而言之，JXTA 的设计目的之一，就是希望能够成为不同 P2P 系统之间的连结桥梁。

第二个例子我们假设的是「储存媒体」的问题。假设一个工程部门中的团队成员，需要一个具有弹性的储存形式来存放共有的设计资料。由于需要较具安全性的存放方式，因此会需要重覆储存进而避免资料漏失。在这种情形下，最为常见的解决方式，就是添购一部高容量且具有资料镜像备份（ mirror ）的磁碟阵列系统。接着可能也会有另一个工程部门的团对也添置了这样的设备。这样一来，两个部门团队可能都付出了较为高昂的代价，但是却无法充分利用另一团对所闲置的磁碟空间。在这种情形下，使用 JXTA 技术，将可以避免购置昂贵的系统，同时又可以不需应用标准的镜像备份方式，而改为利用其他端点的闲置空间，来进行资料的备份。

升阳 JXTA 的运作层次

在 JXTA 所规划的层​​次方面，目前分为三层请参见（图四），分别是核心层次、服务层次、以及应用层次，分述如下：

《图四 JXTA运作模型所规划的层次》

1.核心层次（ core ）

这个层次仅涵盖了最基本的 P2P 应用网路元素。包括端点的定义、端点群组、端点的寻找，端点间的通讯、端点的监控、以及最基本的安全性制等等。这个层次是所有型态 P2P 应用都会共同使用的部分，也就因为如此，不同 P2P 应用之间的沟通与合作才有可能。

2.服务层次（ services ）

这个层次包含了许多常用、有用，但是并非绝对必要的网路服务，如搜寻、索引、目录功能、储存功能、档案分享、分散式档案系统、资源分享、协定转换、授权等等。

3.应用层次（ applications ）

这个层次包含了 P2P 的即时讯息传递、资料内容管理与传送、P2P 邮件收发、分散式的竞价系统等等。

至于在「通讯协定」方面，JXTA 一共定出了六种网路协定，而在 P2P 应用程式部分，只需要实作出自身所需的协定即可，请参见（表三）的说明。