BT 檔案的存活率問題

BitTorrent (BT) 無可否認是一種可以快速分發檔案的技術，可是相對於其他分發技術， BT Network 中的檔案存活似乎低一點。如果是一般的 Server，就通常會比較長，視乎上載者何時把檔案刪除。BT 以外的一些 P2P Network，例如現在較多人用的 eDonkey/eMule Network（以下只簡作 eMule Network），檔案的存活率通常都比 Server 的短，但就比 BT 的長。

首先談談 eMule Network 檔案的存活率。比 Server 的低是很明顯的。Server 中的檔案，只要不刪除的話，就一直保存著，供人下載。但 eMule 中的檔案，就很視乎上載者有否在線和有否把檔案放進 eMule 的上載列。如果只有很少 eMule Client 有相同的檔案，而連最後一個檔案被那使用者刪除於 eMule Network 之外，那該檔案便會消失。可是，如果這檔案是十分普及的，那樣該檔案消失的機會便會減低很多。

BT 檔案的存活率就關乎是否有人上載和檔案是否完整。一般來說，只要下載團隊（Swarm）中有種子 (Seed) 的話，那就應該可以成功下載所有檔案。可惜，由於不同的理由，下載者完種後便立刻停止上載（離開 Swarm）。這樣的使用模式很明顯會限制了檔案的存活時間為幾天至幾星期 (視乎檔案的受歡迎程度)。如果過了檔案的存活時間，就會因為失去了種子使當時的下載者未能完種。

對於這問題，我以前也提出過可行的方法，就是 BT 應聯合 eMule 來分享檔案。BT 可以利用其同時上下載的技術，快速的分發檔案。另外，利用 eMule 較長時間的檔案存活率，作為 BT 補種之用。即是如果某個 Piece 未能在 BT Swarm 中找到的話，就可以在 eMule Network 中找。BitComet 是首隻 BT Client 作出以上嘗試。BitComet 為了使 Client 可以在 eMule Network 找到對應的檔案就加入了種子上載者 (Seed Maker) 可以在 Torrent 檔中加入檔案的 eMule Checksum Hash 的功能。

另外，Torrent 檔中可以加入單一或者多個檔案，但由於 BT 當初其實並未考慮到多個檔案其實會帶來未檔案存活率下降的問題，所以設定 BT 協定的時候當數個檔案為一串單一並相連的資料串來分發。問題就發生於檔案與檔案相連的 Piece。隨著眾多的 BT Client 快速發展，使用者可以在多個檔案的 Torrent 中選擇需要的檔案下載。例如 Piece 123 是檔案 A 和檔案 B 共用的。以前的 BT Client 只會下載屬於檔案 A 或者檔案 B 的部份，另外的部份就不會寫入硬盤而丟掉。在其他的 BT Client 上來看，Piece 123 是不完整的，即是未下載完的，以 BT 的協定，Client 是不會上載這個 Piece 的。如果經過檔案下載的高峰期，大部份的種子的離開了 Swarm 而剩下只下載了部份檔案的上載者，這時 Piece 123 就可能不存在於 Swarm 中，使人們未能完種。雖然可能分別有人有完整的檔案 A 或檔案 B，但 Piece 123 卻顯示為不完整而未能上載，使所有檔案未能完整上載。

已經出現的解決方法有兩種，分別由 BitComet 和 µTorrent 實現的。BitComet 的解決方案如下: 在現存的 BT Specification 中，在不同的檔案中加入緩衝的資料串，即是在每個檔案的結尾加上沒意義的資料，直至檔案結尾填滿一個 Piece，令兩個相連的檔案不會共用一個 Piece。這個方案是從一開始製作 Torrent 檔時就把檔案相連的 Piece 分拆，解決共用 Piece 的問題。不過，這方案有兩個問題，都是與不支援這方案的 BT Client 相關的。

第一，對於那些用於緩衝的資料串，BitComet 會自動識別並不會下載; 但其實的 BT Client 不會自動識別而只會盲目的下載 ，浪費了寶貴的頻寬。對於 Torrent 中有多個小檔案（例如只有數 KiB），但由於其中一個是大檔案（例如數百 MiB），使 Piece 的大少要定在 512KiB，那緩衝資料的大小，相對於真正的檔案便會很大了（~20%-30%），做成很大的浪費。

第二，對於沒加入這種技術的 BT Client 製造出來的 Torrent，BitComet 顯得無能為力，Piece 不完整的問題仍舊存在。對於這問題，µTorrent 提供了另一解決方案，如下：相連檔案的 Piece 會整個下載到硬盤，Piece 不需要的部份會被儲存到另一個暫存檔（Temporary File）中，以保持 Piece 的完整性，延長檔案壽命。

對於現在的情況，很難說那種方案會較好，在我來看，似乎兩種技術一起用會有更好的效果。不過要真正解決問題，提出新的 BT Specification 才是最佳辦法。可惜 BT 作者 Bram Cohen 似乎未有繼續開發 BT2 的意圖，技術也只停留在舊 BT 的層面上。