把P2P進行到底：講述Jxta的故事(2)

2019-11-18 12:19:02

字體：大中小

來源：轉載

供稿：網友

　　在 Jxta 1.0 規范中，一個運行中的服務實例總是和一個對等機聯系在一起（您可以把它想象成是由一個對等“服務器”主管的）。在一個對等組內，只能有一個服務實例和指定的對等機聯系在一起。這種類型的服務被視為對等服務；假如主管該對等服務的對等機當機了，那么將無法獲得該服務。另一方面，同一服務的多個實例被冗余地安裝在一個對等組內的多個對等機上，這被稱為對等組服務。對等組服務是 Jxta 網絡的高可用性和容錯性的要害。Jxta 應用的實現者可以自由地把任意 Jxta 服務作為對等服務或對等組服務進行安裝。管道服務，即為對等通信提供邏輯管道抽象的核心 Jxta 服務，經常被作為對等組服務來實現，以確保其總是可用。
　　
　　管道正如 Jxta 規范定義，在對等機之間傳輸數據、文件、信息、代碼或多媒體內容的一種方式是通過邏輯管道。Jxta 管道用于在對等機之間發送消息（可帶任意內容）。
　　
　　一個管道實例，從邏輯上講，是對等組內的一個資源。管道實例的實際實現通常情況下是通過管道服務完成的。與傳統（類似 UNIX 的）的系統不同，Jxta 管道是單向的、異步的。需要雙向通信的兩個對等機將不得不創建兩個獨立的管道實例。也跟傳統機制如 UNIX 管道或 TCP/ip 套接字不同，Jxta 管道的末端可以在不同的時間連接到不同的對等機上，或者根本不連接。在為 P2P 網絡上的服務提供冗余實現方面，只此一個單一概念就是革命性的一步。對等機可以在任一點及時邏輯地“拾起”管道。例如，設想一個想使用拼寫檢查器服務的對等機。它可以連接到一個對等組的拼寫檢查器管道（該管道是被作為冗余對等組服務實現的）上。在這種情況下，只要至少有一個拼寫檢查器的實例還在該對等組內的某個地方運行，該對等機就還能得到服務。
　　
　　Jxta 1.0 規范提供了兩種一般類型的管道：點對點和廣播（PRopagate）。
　　
　　對等機可以使用點對點管道連接到另一個對等機并單向傳輸消息。對等機可以使用廣播管道連接到一個或多個其它對等機并向它們全體傳輸消息。從本質上講，點對點管道是一對一的消息傳輸機制，廣播管道則是一對多的消息傳輸機制。Jxta 社區目前正在多對多消息傳輸機制方面努力；這個機制已經被命名為 Jxta 導線（wire）。不管是什么類型的管道，通過管道載送的信息塊都稱為 Jxta 消息。那么，這些消息的確切格式是什么樣子呢？
　　
　　消息 Jxta 消息是通過管道從一個對等機傳送到另一個對等機的數據束。這里，Jxta 規范再一次盡可能地使自己普遍適應，以免不經意間在消息的定義中引入任何依靠于實現的策略。消息被定義為由信封和正文組成的任意大小的束。信封是標準格式，它包括：
　　
　　報頭
　　源端點信息（URI 格式）
　　目的地端點信息（URI 格式）
　　消息摘要（可選的出于安全性目的）
　　消息正文的長度是任意的，可以包含一個可選的信任狀（出于安全性目的）和內容。
　　
　　請注重，Jxta 消息的定義非常松散?？紤]到我們日常一般都是在可靠的、寬帶的 TCP/IP 網絡上操作，這樣做的必要性并不是立即可以明了的。但 Jxta 消息的格式必須是靈活的、善于適應新環境的，因為它可能要在所有種類的網絡上實現，而不只是在 TCP/IP 上。設想在一個支持 256 字節數據包的不可靠傳輸的網絡（象傳統的基于數據包的無線網絡）上的一個 Jxta 實現，您就會對 Jxta 消息的簡單定義如何使自己適應諸如這樣的不利環境表示贊賞。
　　
　　為了提供一個標準的、語法上易分析的、通用的編碼機制，Jxta 消息目前采用 xml 文檔格式。Jxta 利用了 XML 的普遍可訪問性和易使用、易編程的特點，這意味著 Jxta 可以用大多數編程語言在大多數平臺上很輕易地實現。只要 XML 語法分析器和生成庫在那里是可用的。然而，Jxta 本身的設計卻使其消息代碼的編寫不依靠于 XML 的使用。雖然現在不太可能，但 Jxta 社區在規范的未來版本中包含（或要求）基于非 XML 的消息是完全可能的。
　　
　　關于 Jxta 標識符從潛力上講，對等組或許可以跟整個聯系著的宇宙一樣大。在這么大的名稱空間中為任何事物進行唯一的命名都是一個挑戰。為了應對這個問題，Jxta 給 Jxta 組件的每個可設定地址的實例都分配了一個內部標識符。這種標識是通過一個 UUID 進行的，UUID 是使用能夠確保在時間和空間上都有很高概率的唯一性的算法產生的 64 字節的數字。Jxta 標識符是 URN（統一資源名稱）格式的，并被嵌入到廣告中供內部使用。目前定義了四種標識符類型，用于標識對等組、對等機、管道和代碼／數據（code/data）（簡寫為 codat）。
　　
　　廣告
　　廣告有點像是消息的“堂兄弟”。Jxta 廣告也采用 XML 文檔格式。廣告的內容描述了諸如對等機、對等組、管道或服務等 Jxta 組件實例的屬性。例如，可以訪問另一個對等機的廣告的對等機可以設法直接連到該對等機上；可以訪問一個對等組的廣告的對等機可以通過廣告加入對等組。目前的因特網中與廣告相似的東西是域名和 Web 站點的 DNS 紀錄。Jxta 規范沒有規定如何創建、傳播或銷毀廣告。
　　
　　互操作性的基礎：Jxta 協議互操作性的另一個要害是這樣一個事實：核心 Jxta 對等交互操作模型被完全表示為在底層網絡上傳輸的一套簡單協議。換句話說，既然協議和消息格式是定義完好的，那么基于 Jxta 的系統間的互操作性完全可以在導線一級上達到。
　　
　　例如，一個簡單的 PDA（8 位處理器，基于 C 語言編程）就可以是一個運行在基于數據包的無線網絡上的 Jxta 對等機，它可與同一對等組內的各種系統，從 PC 服務器到大型機，進行交互。假如這些對等機共享一個公共網絡（傳送）并正使用 Jxta 協議和消息格式進行通信，這是可以做到的。
　　
　　Sun 已為 Jxta 提供了初步的 java 語言實現。Jxta 社區現在擁有這個參考實現。這個參考實現為那些想馬上使用 Jxta 的 Java 程序員把事情變簡單了。而假如您正在非 Java 平臺上實現 Jxta，那么理解這些協議就是非常重要的。表 2 簡要描述了 Jxta 協議的核心集，涵蓋了發現（對等機如何找到對方）、廣告（對等機如何讓別的對等機了解對等組、管道等信息）、通過管道進行的通信和對等組成員資格的處理。下面的所有協議都是建立在傳送器上的 XML 消息交換的基礎上的。同樣地，它們可以用幾乎所有的編程語言在幾乎所有平臺上實現。
　　
　　表 2. Jxta 核心協議
　　把P2P進行到底：講述Jxta的故事(2)

　　Jxta 規范不要求對等機實現上述所有協議。任一特定的對等機只須實現那些實際要用到的協議。
　　
　　基于 Jxta 的系統的一些有趣的屬性
　　既然您已經對 Jxta 平臺理論上的構件有了一個基本理解，我們就來討論一下作為 Jxta 設計結果的一些有趣的屬性。
　　
　　有“電子心跳”的任何東西都可以成為一個 Jxta 對等機，從理論上說，有文本字符串生成能力的最簡設備都可以加入（雖然并不是在每個 P2P 應用中都有必要）到 Jxta 網絡中。這是怎么成為可能的呢？
　　
　　在 P2P 網絡上，過分簡化的設備需要對等代理人。這個代理人可以代表該簡化設備（或多個簡化設備）執行發現、廣告和通信。代理人的位置可以被硬性固定在簡化設備。這樣，在代理人的幫助下，簡化設備就可以成為 Jxta 網絡上完全合格的對等機。例如，一個被綁在一只海龜身上并以無線方式發送出帶有位置信息的 Jxta 消息的 GPS 定位器，就可以成為 Jxta 網絡上的一個對等機。
　　
　　不確定拓撲結構的網絡中的順序
　　典型 Jxta 網絡另一個迷人的方面是它固有的不確定的拓撲／響應結構。計算機用戶通常都習慣于本質上確定的、同步的計算機系統，并認為這是一種標準結構。例如，當我們的瀏覽器發出 Web 頁面的一個 URL 請求時，我們期望輸出馬上就會出現。我們還期望世界上的每個人都可以使用同一個 URL 從同一個 Web 服務器檢索同一個頁面。
　　
　　在 Jxta 世界里，一個特定的資源請求不會在幾分鐘、幾小時或甚至幾天內返回；事實上，它可能根本就不會返回。另外，請求同一資源的世界各地的人們很可能得到的是來自完全不同的服務器的資源副本。這就引起了一個問題：不確定性系統有什么好處呢？
　　
　　來自 grassroots 軟件革命的靈感
　　我們只要看看象 Napster 和 Gnutella 這樣的流行 P2P 系統就可以找到答案。下面是它們的一些額外的優勢特征（它們使同步性和確定性的喪失變得值得）：
　　
　　內容的高可用性。
　　對等機可以從多個服務器上獲取內容，理想情況下可從四周開機運行著的一臺服務器上獲得。原始源對等機不必為每一個資源請求服務；事實上，它甚至可以不開機運行。網絡帶寬的最優化使用。
　　現今 Web 上典型的局部流量集中導致的擁塞不會影響 P2P 網絡。
　　
　　更低的內容分發成本。
　　P2P 網絡能吸納內容并復制它以使它易于存取。
　　
　　來自網絡中各個節點的計算能力的均衡。
　　通過異步操作，您可以同時發出許多資源或服務請求，然后讓網絡為您完成這些工作。
　　
　　無限的可伸縮性。
　　一個設計良好的 P2P 應用可以在不影響可伸縮性限制的情況下橫越整個已知的連接著的宇宙；而這在任何集中式模式中是完全不可能的。
　　
　　在完美的 Jxta 世界中，我們將在不確定性網絡上執行異步請求。您覺得這個概念古怪嗎？讓我們用一個示例來闡明。設想一個在基于 Jxta 的 P2P 網絡上運行的基于網絡的音樂請求服務。對等機提交了幾個對音樂文件的請求并在一段時間后核查對等組中的音樂請求服務是否找到了這些文件。當我們在一段時間后去核查音樂請求服務時，所請求的一些文件已經被找到，但其它的卻無法定位。服務對那些文件的響應是：音樂的選擇和可用性在不斷地變化；請稍后重試您的請求。這是一個可接受的不確定的結果：雖然服務未能找到一個文件

上一篇：Peer-to-Peer Sockets 工程入門

下一篇：構建Java并發模型框架