From: http://mmdays.wordpress.com/2007/04/14/bt4/
透視BT（四）──為什麼BT沒有內建搜尋功能?
四月 14, 2007 作者：Days
前幾篇BT系列文刊出之後迴響熱烈, 看來大家都有聽過BT的名頭, 或多或少也都曾經下載過 , 不過對於BT在各種層面的影響似乎沒有非常深的認識. 今天要來討論的主題顯然也是許多使用者長年以來的疑問: 為什麼BT沒有內建搜尋功能 ? 雖然真正的答案可能只有Bram Cohen才知道, 不過這裡將從P2P軟體設計及網站架設的困難度, 試著尋求合理的解釋.
如果你想用P2P軟體下載檔案, 不論你使用哪種程式, 一貫的動作順序是:
輸入關鍵字 -> 找到檔案資訊 -> 進行下載
以往的分享軟體自Napster以降, 都包含了整套的配件, 讓使用者可以一氣喝成的完成從搜尋到下載的動作. 然而到了 BT, 卻變成
輸入關鍵字(在別的論壇) ->找到檔案資訊(在別的論壇) -> 連線到BT tracker(在BT端) -> 進行下載(在BT端)
變成兩段式的了. 換言之, BT下載機制本身完全跳過搜尋的過程, 它完全是在』使用者已經找到要的檔案了, 只缺下載』的假設下運作. 為什麼會這樣? 最可能也最合理的猜測是, 搜尋這件事比大家想像得還要困難, 尤其是在P2P網路中.
今天有很多人對於』P2P』的印象都停留在ezPeer, Kuro跟Foxy這些下載軟體, 事實上這些軟體的流行在極大的程度上誤導了很多使用者: 它們在結構上都不是真正純粹的P2P . 真正學術上對P2P的定義是: 任何角色隨時都可以被其他人所替代的一種合作模式. 純粹的P2P是什麼意思呢? 讓我舉個例子. 假設今天是某間國小開學的第一天, 老師來了, 告訴同學們要選一個班長. 推舉班長的方法當然很多, 以下是兩種可能的方式:
1. 由老師直接指定
2. 同學們互相推舉, 最後投票選出來一個班長. 選舉過程老師沒有插手干預.
第一種投票方法, 屬於非常典型的』主從式架構』,英文稱之為client/server model. 在這種架構中, 存在著一個幾乎是全知全能, 其他人無法取代的角色:Server(本例中是老師). 由Server對其他人發號司令. 這種作法的好處是號令統一, 命令的傳達非常迅速, 缺點是client(學生)一多server(老師)就難以招架, 而一旦老師招架不住掛點之後, 學生就會群龍無首,難以控制.
第二種方法, 則是標準的』純P2P式架構』, 英文稱之』Pure P2P』. 在推舉過程中, 每一個人都處在平等地位, 都有可能選上班長. 而選上班長的人雖然可能暫時來講會比其他同學高一級, 但由於他是從一般同學中推選出來的, 一旦被發現不適任, 大家隨時可以再用相同投票方法從同學中選出新班長. 這種作法的好處是, 如果投票的方法設計得好, 是可以讓幾千幾萬個同學在幾分鐘間選出新班長的, 而且不用擔心若有人缺席會導致無法選出班長.
P2P被應用在很多場合, 比如說還在發展中的sensor network, 或是各種無線通訊裝置(例如手機)如何在沒有基地台的情況下與其他手機連絡等等. 當然, 網路下載也可以是一種. 以前面的例子來解釋, P2P下載就像是把全世界的網友都被視作是班上的一個同學, 檔案交換則視為是同學間私下互相交換小玩具. 然而此時麻煩就出現了, 如果沒有領導者如老師或班長的幫忙, 一個同學要如何知道哪個同學有他想要的玩具呢?
如同前面的例子, 搜尋的方法也分成兩種, 一種是主從式架構型的, 一種是純P2P式的. 很不幸的, 純P2P式的搜尋到目前為止, 可說都是非常沒有效率的(只有極少極少的例外). 純P2P型搜尋方式的代表為Anthill. 顧名思義, 搜尋的過程就像螞蟻找食物, 使用者發出很多小小隻的螞蟻, 挨家挨戶的去敲門, 看看有沒有好心人願意提供使用者想要的食物. 有的話就傳送回來. 沒有的話? 只好認栽. 事實上因為網路使用者眾多, 小螞蟻們根本不可能爬完所有門戶, 所以這種搜尋方式也不能保證找到應該要有的檔案. 這種略帶殘缺的搜尋方式被應用在早期的Gnutella, FreeNet, 以及現在日本的winny.
主從式的搜尋方法就比較有效率. 一開始由一個人負責匯整班上所有同學手上的清單, 然後再讓同學根據清單來找尋他想要的玩具. 不會出現』明明網路上有人有檔, 為啥程式告訴我找不到』的現象. 早期大紅的Knapster就是這類的代表. 不過就如同我前面所說主從式的缺點: 雖然有效率, 可是遇到人多的時候就會塞車, 伺服器端的資源耗得又凶又快. 不僅如此, 在數位音樂時代, 又多了一項大缺點: 容易被告! Knapster的伺服器因為擁有所有人的檔案清單, 一下子就被RIAA給告倒了. 伺服器掛點後, Knapster有如樹倒猢猻散, 曾經擁有的數百萬名使用者從此轉投他人懷抱, 即使多年之後Knapster 2.0再起, 也無法回到當年榮景.
所以P2P式的下載環境就沒辦法兼顧有效率的搜尋方式, 同時避免被告的風險嗎? 為解決這個問題, 出現了現在大家所熟知的KaZaA 以及 eMule. 這兩種檔案分享軟體的作法處於上述兩者中間, 兼顧了主從式的搜尋架構, 以及純P2P式不因單一伺服器故障就整個系統掛掉的優點. 這種方法稱之為: 混合式P2P (Hybrid P2P)
相信看到這個圖就很好理解了吧! 在混合式P2P架構中, 存在著一批伺服器. 每一台伺服器服務一部分的使用者. 當使用者想找檔案時, 伺服器先找找看自己手上的名單中有沒有符合的, 同時也順便問問其他伺服器有沒有看過這個檔案. 這種做法稱為混合式的原因是, 說它是主從式嘛…伺服器間是以純P2P的方式合作, 說是純P2P嘛, 又存在著一般使用者與伺服器的分野, 彼此不能互換. 因為難以界定到底是哪種, 所以被稱為混合式. 混合式P2P算是兼顧了主從式架構在搜尋上的效率, 也舒緩了單一伺服器的效能瓶頸. 如果其中某一台伺服器掛了, 至少還有別台當候補. 混合式P2P好處眾多, 也因此成為eDonkey, eMule, KaZaA等軟體的主要架構, 但唯一的缺點就是, 還是需要相當多的資源, 才能架起一台伺服器.
看到這裡, 大家應該多少開始對BT為什麼沒有內建搜尋機制心底大概有個譜. KaZaA是一家商業公司, 找資金來架伺服器不是問題(尤其現在KaZaA公司又出了Skype, 應該賺翻了). eMule前身是eDonkey, eDonkey也是由一家叫MetaMachine的公司所開發的, 因此草創初期的Server也不愁沒有人出資來架. BT的開發者Bram Cohen呢? 很抱歉, 他顯然什麼資源都沒有. 從Mr. Friday 自己的角度出發, 如果今天我沒錢去架混合式P2P所需要的Server, 又忍受不了純P2P式極爛的搜尋環境, 那我會怎麼做呢? 乾脆不做搜尋功能 . 我們今天看到的BT程式, 都假設使用者已經找到要下載的torrent檔了, 很顯然就是在這種情況下誕生的. 也因此, BT大量仰賴全世界各地的論壇, 因為若沒有這些論壇提供BT檔搜尋功能, 很多人大概一輩子也找不到他要的torrent檔在哪邊. 那麼未來BT有沒有辦法再修改程式, 改成eMule那樣子, 可以自動搜尋torrent檔在哪? 我不知道, 不過顯然很困難, 因為重寫程式是一件很麻煩的事情, 而且從Bram Cohen的網頁上看來, 他的重心已經不在維護BT程式碼上面了.
那麼BT現在發展出的DHT技術呢? DHT技術也是一種純P2P式的機制, 目的在把Tracker(仔細想想會發現, 這是BT中唯一以主從式架構設計的東西)架空, 變成完全由使用者分擔紀錄使用者名單的機制 : 每個人分別紀錄一些名單, 連線時只要先找到一個人就可以逐漸得到所有人的名字. 由於有些超級使用者總是在線上, 參與下載的BT檔又多, 因此手上有各種BT檔的參與成員名單, 隱隱然有一點eMule伺服器的味道, 那透過搜尋這些超級使用者手上的BT紀錄來實現搜尋功能呢? 嗯, 這是個可行的做法, 但是還需要一段時間的發展, 畢竟在BT裡面並沒有針對搜尋來做最佳化的演算法: 如何有效率的儲存每個人手上的BT人員名單? 用什麼方法來搜尋超級使用者(派出螞蟻雄兵在超級使用者家門口敲門, 超級使用者家會被塞爆唷, 真正厲害的搜尋法不用派出那麼多人就可以找到想要的資訊了)? 甚或是怎麼判定哪些人是超級使用者… 這些問題若沒有好的解答, 那BT在搜尋這方面就還有很長的路要走.
透視BT系列在這邊暫時告一個段落, 接下來會不會再寫P2P相關應用的系列? 也許會, 不過就要看有沒有讓我感興趣, 覺得值得介紹給大家的內容囉!
p.s. 最近看到一篇PPStream, PPLive, Sopcast等網路電視的流量測試報告, 雖然這些程式本身設計方式都是保密的, 但是從測試報告中可以讀到什麼? 嗯嗯, Mr. Friday 還在鑽研中, 不過看來蠻有趣的喔, 也許之後會寫一篇也說不定!
相關連結