P2P 應用程式架構

這個月，我将不在高層次領域（高達 1000 英尺）繼續讨論，也不解決安全性問題，相反，我将在低層次領域（50 英尺）讨論應用程式架構。

我真誠地希望這個轉變将比現實生活中經常遇到的轉變更令人愉快。

讓我們從安裝的具體細節開始。我略微更改了啟動 P2P 應用程式的過程，因為在上個月，一些讀者在啟動應用程式時遇到了問題。

下載下傳這些檔案之後，将這兩個 jar 檔案和包含配置檔案的目錄添加到類路徑中。

如果您正在運作 Windows，并且已經将這兩個 jar 檔案和配置檔案下載下傳到 c:\p2p 目錄，則可以如下設定類路徑：

如果您正在運作 Linux、Solaris 或某個合适的 UNIX 變體，并且已經将這兩個 jar 檔案和配置檔案下載下傳到 /home/foo/p2p 目錄，可如下設定類路徑：

（以上指令假設您正在運作 BASH 來作為指令 shell）。我将如何在其它流行的 shell（如 CSH）中設定環境變量的問題留給您自己去考慮。

一旦設定了類路徑，就可以用以下指令啟動應用程式：

P2P 應用程式将顯示一個别緻的資訊性标志和一個指令提示來歡迎您。

最後再說一遍：我的 P2P 應用程式一定需要 Java 2 平台。

前幾步将啟動并運作 P2P 應用程式，但是，在能夠很好地使用它之前，必須編輯配置檔案。配置檔案定義 P2P 應用程式使用的端口、控制的資源以及識别的夥伴。清單 1 示範了每一個定義。

第一部分由一行組成，它定義了 P2P 應用程式用來接收其它夥伴連接配接請求的端口。最好不要改變這行。

第二部分定義 P2P 應用程式管理的資源。您可能需要編輯這部分。清單 1 定義了兩個資源：<code>share</code> 和 <code>tmp</code>。從應用程式的觀點來看，資源隻是實作 <code>Resource</code> 接口的類的執行個體，我們将馬上講到這點。資源定義一般具有以下基本形式：

name 是給予資源的名稱，它用來生成人們可讀的輸出。class 是 Java 類的名稱，可以将其初始化以建立資源。P2P 應用程式在運作期間動态裝入這個類并将其初始化。在其初始化期間，argN 自變量被傳遞到新初始化的資源。例如，<code>FileResource</code> 類使用這些自變量定義目錄來為檔案提供服務。您需要編輯目錄自變量以指向您機器上的某個目錄。

第三部分定義 P2P 應用程式識别的夥伴。每一行都包含夥伴的名稱（或 IP 位址）和夥伴的端口。用這種方式定義夥伴顯然不是可伸縮的解決方案。在以後的文章中，我們将看一種更好的解決方案。

除了對等通信采用的 SPP（簡單點到點）包之外，P2P 應用程式不包含很多類。首先，我們先仔細檢視最重要的類，最後再看一下 SPP 通信包。

<b>資源</b>

P2P 應用程式的主要元件是資源。事實上，P2P 應用程式隻是允許和控制對已釋出資源的遠端通路。資源可以是任何可尋址的事物 -- 檔案系統、電話簿、資料庫和目錄。每個資源都管理零個或多個适當類型的項（檔案系統資源管理檔案，電話簿資源管理電話号碼）。

為示範如何實作資源，我建立了一個簡單的檔案系統資源類 <code>FileResource</code>，如清單 3 所示。這個檔案系統資源管理零個或多個檔案。

<code>Resource</code> 接口定義資源的結構和行為。該接口還定義允許在資源上執行的操作。目前的操作清單包括 select。以後的實作還将包括 insert 和 delete。

<code>select()</code> 方法将一個定義選擇标準的字元串作為參數。該方法傳回有關所有與選擇标準比對的資源項的資訊。按照目前 P2P 應用程式中的檔案系統資源所實作的方式，選擇字元串既可以直接命名一項，也可以包含通配符 "*"，當直接命名一項時，資源将傳回該項本身及其相關中繼資料；當包含通配符時，資源将隻傳回它所管理的所有項的中繼資料。還可以使用更複雜的查詢語言，但這不在本文讨論範圍之内。

<b>Shell</b>

<code>Shell</code> 類隻是一個允許使用者浏覽本地和遠端資源的非常簡單的指令行使用者接口。它使用 <code>PeerReference</code>、<code>ResourceReference</code> 和 <code>ItemReference</code> 類向其它夥伴發送請求，但它本身隻分析使用者輸入。

<b>通信</b>

P2P 所做的全部就是夥伴間的通信。那些對原始得令人難以置信的 Napster 協定熟悉的讀者應該了解我為什麼選擇進階一些的協定。我在這裡隻略微提及 SPP。在以後有關 P2P 通信的文章中，我将較長的描述它。

SPP 将消息模組化成一個幀序列，如圖 1 所示。

消息中的每一幀都有一個類型（由 MIME 類型指明）和一個主體。幀中的頭是可選的，它用來描述主體中的資料。

構成完整而正确的消息的序列中的幀類型取決于應用程式。一般來講，一條消息由一個控制幀和其後零個或多個資料幀組成。資料幀包含控制幀所引用的資料。我們的 P2P 應用程式就采用這種模式。

消息出現在請求／響應對中。一個夥伴向另一個夥伴發送請求。那個夥伴再将響應發回給第一個夥伴。

請求消息中的控制幀是指令幀。它包含指令和為該指令提供的所有參數。如果有任何其它幀存在，則這些幀包含指令幀所需的資訊。

響應消息中的控制幀是狀态幀。它包含狀态（正确或錯誤）。如果有任何其它幀存在，則這些幀包含狀态幀所引用的資訊。如果向檔案系統資源送出請求，則該資訊将包含所選檔案的内容。

完全了解了架構之後，我們就可以在下個月繼續讨論 P2P 安全性了。我們還将在 P2P 應用程式中內建安全性支援。