所以P2P式的下載環境就沒辦法兼顧有效率的搜尋方式, 同時避免被告的風險嗎? 為解決這個問題, 出現了現在大家所熟知的KaZaA 以及 eMule. 這兩種檔案分享軟體的作法處於上述兩者中間, 兼顧了主從式的搜尋架構, 以及純P2P式不因單一伺服器故障就整個系統掛掉的優點. 這種方法稱之為: 混合式P2P (Hybrid P2P)
相信看到這個圖就很好理解了吧! 在混合式P2P架構中, 存在著一批伺服器. 每一台伺服器服務一部分的使用者. 當使用者想找檔案時, 伺服器先找找看自己手上的名單中有沒有符合的, 同時也順便問問其他伺服器有沒有看過這個檔案. 這種做法稱為混合式的原因是, 說它是主從式嘛…伺服器間是以純P2P的方式合作, 說是純P2P嘛, 又存在著一般使用者與伺服器的分野, 彼此不能互換. 因為難以界定到底是哪種, 所以被稱為混合式. 混合式P2P算是兼顧了主從式架構在搜尋上的效率, 也舒緩了單一伺服器的效能瓶頸. 如果其中某一台伺服器掛了, 至少還有別台當候補. 混合式P2P好處眾多, 也因此成為eDonkey, eMule, KaZaA等軟體的主要架構, 但唯一的缺點就是, 還是需要相當多的資源, 才能架起一台伺服器.
那麼BT現在發展出的DHT技術呢? DHT技術也是一種純P2P式的機制, 目的在把Tracker(仔細想想會發現, 這是BT中唯一以主從式架構設計的東西)架空, 變成完全由使用者分擔紀錄使用者名單的機制 : 每個人分別紀錄一些名單, 連線時只要先找到一個人就可以逐漸得到所有人的名字. 由於有些超級使用者總是在線上, 參與下載的BT檔又多, 因此手上有各種BT檔的參與成員名單, 隱隱然有一點eMule伺服器的味道, 那透過搜尋這些超級使用者手上的BT紀錄來實現搜尋功能呢? 嗯, 這是個可行的做法, 但是還需要一段時間的發展, 畢竟在BT裡面並沒有針對搜尋來做最佳化的演算法: 如何有效率的儲存每個人手上的BT人員名單? 用什麼方法來搜尋超級使用者(派出螞蟻雄兵在超級使用者家門口敲門, 超級使用者家會被塞爆唷, 真正厲害的搜尋法不用派出那麼多人就可以找到想要的資訊了)? 甚或是怎麼判定哪些人是超級使用者… 這些問題若沒有好的解答, 那BT在搜尋這方面就還有很長的路要走.
沒有留言:
張貼留言