對等應用程序是一種大規模但又是細粒度的應用程序。每個對等點都可以進入或退出 — 每個對等點都關注於自己的任務。在他們短暫的活動期間，嘗試完成佈置給它們的任務。這些任務中的大多數都要涉及與其它對等點交互。
管理體系結構（對等點在這種體系結構下運作）必須爲構成完整 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 應用程序代碼的附加部分將消除一個最大的問題 — 對等點的點到點配置。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=2205275