前言

這一陣子以來，對於點對點（ 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 應用程式部分，只需要實作出自身所需的協定即可，請參見（表三）的說明。