對等點如何彼此定位

導讀：

　　要完成有用的工作，P2P 應用程式中的對等點必須能夠彼此發現對方和與對方互動。軟體開發人員 Todd Sundsted 在本文中繼續研究 P2P 計算，并描述了幾種完成這一任務（稱為發現（discovery））的方法，以及每種方法的優勢和弱點。

　　對等應用程式是一種大規模但又是細粒度的應用程式。每個對等點都可以進入或退出 — 每個對等點都關注于自己的任務。在他們短暫的活動期間，嘗試完成布置給它們的任務。這些任務中的大多數都要涉及與其它對等點互動。

　　管理體系結構（對等點在這種體系結構下運作）必須為構成完整 P2P 應用程式的對等點提供許多必要的服務。在我們的 P2P 計算“旅程”中，已經講述了通信和安全性服務（請參閱參考資料）；現在是時候來研究對等點發現服務了。

　　對等點發現服務使 P2P 應用程式中的對等點能夠彼此定位以便互相之間可以互動。實作對等點發現服務有多種方法。我們先從告訴對等點彼此之間的存在這種最簡單的方法開始：顯式點到點配置。

　　顯式點到點配置

　　顯式點到點配置與其說是一種真正的發現機制，還不如說是一種用來避免實作發現的機制。每個存在的對等點都知道“居住”在其 P2P 世界中的其它對等點。

　　術語點到點（point-to-point）意味着，在 P2P 應用程式中的每個對等點都知道需要不斷與之互動的每個對等點，并與之相連。這種連線不必将每個對等點都連起來 — 将每個對等點和其他各個對等點彼此相連，是不太可能的 — 但是，不這樣做（無論是有意與否）将會使某些對等點産生網絡盲點。

　　我為本系列文章所建構的簡單的 P2P 應用程式（請參閱參考資料）使用顯式點到點配置。每個對等點必須預先配置其它所有對等點的位址。如果您已經下載下傳并使用了那些代碼，則您無疑已經經曆了忍受這一需求所帶來的挫折 — 配置既單調乏味又容易出錯，更不用提一般的麻煩了。

　　一般而言，分布式應用程式中節點的顯式點到點配置不能很好地擴充到具有較多節點的大型網絡。那就是為什麼分布式計算應用程式和技術總是（也有一些顯著的例外）包含命名和定位功能。這也解釋了為什麼域名系統（DNS） — 一種分布式命名系統，最終取代了用于機器命名的主機檔案（hosts file）機制。維護主機檔案是單調乏味、容易出錯的，并且一般來說，很難在大型網絡環境下運轉。

　　但是，顯式點到點配置并非一無是處。點到點尋址缺乏靈活性的特性也帶來了一定程度的安全性。通過對網絡中的每個對等點預先設定它所知道并且将要與之互動的對等點清單，使得網絡在外部攻擊面前表現得很穩固。

　　動态發現模型

　　與顯式點到點配置方法的靜态特性截然相反，目錄服務和網絡模型具有動态特性。這些模型通常能更好地符合 P2P 應用程式，它們傾向于該領域中動态的一邊。

　　在下面幾節中，我們将研究三種不同的機制，對等點通過這些機制動态地定位其它對等點和了解它自身所屬的環境。

　　目錄服務模型

　　在目錄服務模型中，一台或多台有特殊用途的伺服器為對等點提供目錄服務。為了使可擴充性最大化，對應用程式進行了結構化設計，以便少量的目錄就可以為數量衆多的對等點服務。對等點向目錄服務注冊關于自身的資訊（其名稱、位址、資源和中繼資料），并通過根據目錄伺服器中資訊的查詢，使用目錄服務來定位其它對等點。

　　圖 1 說明了一個使用目錄來向對等點提供位置和命名服務的 P2P 體系結構。目錄本身可以是對等點（盡管是很龐大的對等點），或者可以隻擔當目錄而不作它用。

　　圖 1，目錄服務模型

　　目錄有兩種類型。這兩種類型因為其目錄集中式管理的程度不同而有略微的差别。

　　P2P 領域中目錄模型的最佳示例是 Napster 和與 Napster 幾乎一模一樣的 OpenNap。在 Napster 模型中，采用集中式管理目錄。雖然，采用集中式管理的目錄遭到“本質上是‘非 P2P’”的指責，并且事實上促使了 Napster 被棄用，但它确實提供了一個重要的優勢：集中式管理使它容易確定伺服器硬體和配置能足以達到服務品質目标。

　　如果我們先暫時将 P2P 放一放，可以發現 DNS 是分散式目錄的一個優秀示例。與網際網路本身相似，DNS 設計為甚至在部分網絡受到嚴重破壞的情況下仍能工作。DNS 目錄采用階層化結構，根目錄代表頂級域（譬如“com”），它将子域查詢服務（如“etcee.com”這樣的域）的任務委派到下一層次的 DNS 伺服器。

　　在任意一種情況下，隻有目錄位置必須配置到每個對等點中，這對于點到點模型有重要優勢。為加入到 P2P，對等點将自己注冊到集中目錄伺服器。回憶上面的圖。當對等點 A 希望與一個它不知道位置的對等點互動時，對等點 A 向目錄伺服器發送請求。然後，目錄伺服器向 A 傳回那個對等點的位置。

　　網絡模型

　　圖 2 說明了另一種 P2P 應用程式。它由許多對等點組成，這些對等點在功能上很類似。沒有專門的目錄伺服器。對等點必須使用它們所在的網絡來定位其它對等點。

　　圖 2，網絡模型

　　

　　

　　正如名稱所暗示的，網絡模型 P2P 應用程式由一些（通常是動态的）對等點組成。沒有一個對等點知道整個網絡的結構或者組成網絡的每個對等點的身份。相反，對等點隻知道直接與它們通信的對等點 — 它們通過代理參與到大型網絡中。

　　對等點必須合作完成任務。在許多環境中這種合作包括支援分布式查詢、分布式消息傳遞，甚至包括認證和授權行為。因為涉及通信量的多少，象檔案傳輸這樣需要大流量的網絡操作通常在對等點間直接發生 — 而不是通過對等點的網絡。

　　思考上面圖 2 中的網絡。當對等點 A 希望知道網絡中另一個對等點的位置時，它就發出一個查詢請求并傳遞給鄰居。這些鄰居嘗試滿足這個請求。如果這些鄰居不能完全滿足這個請求，就将請求傳遞給它們的鄰居，以此類推。

　　要加入網絡，一個對等點要找到願意接受它為鄰居的另一個對等點。但是，當對等點本身還不是網絡的一部分時，它如何找到網絡中的另一個對等點呢？

　　一個可能的解決方案是向這個對等點提供一個對等點清單，讓其檢查。對等點設法聯系清單上的對等點直到一個或多個對等點接受它為鄰居。這個解決方案聽起來很象點到點模型，是不是？正如最初 Gnutella 使用者所證明的那樣，這個解決方案隻是一定程度上有效。因為 P2P 網絡（尤其是 Gnutella）動态性很強，任何靜态清單都不太可能長期有效。

　　進一步研究 Gnutella 這種環境中的解決方案是很有趣的。Gnutella 實作首先将這樣開始：當其它對等點通過網絡傳播發送請求時，Gnutella 捕獲并持久地存儲這些對等點的位置。當這些客戶機關閉後又重新啟動時，它試圖連接配接每個先前辨別的對等點直到找到一個或多個仍在運作。

　　這種方法，雖然自動化程度很高，但是脆弱而且低效。後來，通過添加對從中央緩存下載下傳活動對等點的清單的支援（請參閱參考資料以獲得示例），改進了這種模式下的客戶機。

　　這種模型的一個有趣的方面是，在支援對等點發現的過程中，組成網絡的對等點擔任了非常活躍的角色。正如我們即将看到的，活動對等點的參與并不是必要條件。

　　多點傳播（multicast）模型

　　除了網絡中的節點不必協助發現以外，多點傳播模型和網絡模型很相似。這種模型利用網絡自身提供的特性來定位和确認對等點和資源。這種技術的實作（Sun Microsystems 的 Project Jxta 是一個極佳的示例；有關 Jxta的更多資訊，請參閱參考資料）使用 IP 多點傳播來實作查詢。

　　不象單點傳播（unicast） IP 資料報 — 一台主機，最多隻能向一台主機發送資料報，多點傳播 IP 資料報可以同時發往多台主機。更重要的是，發送方不必知道有多少接收方存在或者究竟有沒有接收方存在。發送主機隻是封裝消息并将它釋出到網絡上。所有調整到适當頻道（特殊 IP 位址和端口号的組合）的客戶機将接收到該消息的一個副本。

　　使用 IP 多點傳播技術的發現通過讓對等點用多點傳播定期宣布自己的存在來工作。該消息包含對等點的 TCP/IP 主機名和端口号。對此消息感興趣的對等點檢測這個消息後，抽取出主機名和端口号，并使用這個資訊與新對等點建立正常的 TCP/IP 連接配接。

　　這就是多點傳播是如何在單個子網上工作的。衆多子網（組成整個網絡）間的路由多點傳播通信是完全不同的，并且是一個非常複雜的課題。這也是基于 IP 多點傳播的發現的主要局限。沒有路由器的支援，基于 IP 多點傳播的發現被局限在同一子網上的對等點之間。不幸的是，網際網路對多點傳播并不友好。通常，網際網路（或大型内部網）上的發現由跨網絡邊界的特殊對等點将消息複制到另一個網絡中來實作。

　　結束語

　　P2P 應用程式的對等點發現是一個有趣的話題。下個月，我們将研究使用 IP 多點傳播來查找活動對等點的對等點發現的實作。這個簡單 P2P 應用程式代碼的附加部分将消除一個最大的問題 — 對等點的點到點配置。

本文轉自

http://www.javazy.com/contentex/20064512151.shtml