商用 BT

BitTorrent (BT) 的分發技術似乎又有新發展。以前，BT 大概可以說是一種民用的技術。這技術是一個普通電腦程式師發明和發揚光大的。自此，就有不少的電腦使用者利用這種技術分發檔案。當中的檔案，我想大部份都是有版權的商品，包括音樂 MP3，電影（VCD，DVD 或已經壓縮的格式）和軟件等。

這種技術大大的加速了分發具版權的檔案，所以一時引起了各商品受益人的反感，想要壓制這種分發檔案的技術。其實，錯不在這種技術，而是那些將檔案於上 BT 網絡上的人。如果我們可以好好的利用這種技術，說不定會為商業世界帶來新契機。

現在已有不少電遊戲廠商將遊戲的試玩版，或者免費網絡遊戲的光碟，以影像（Image）的格式，再利用 BT 分發給玩家。這種分發的方式和以前的有點不同，因為多了伺服器這個原素。以前 BT 多為民用，一般使用者的電腦不太可能長時間上載檔案給下載者，所以如果一旦達到某個上載目標（例如有五個種子），便會停止做種上載，以下便會由已完種的人繼續分發，延讀檔案的壽命。廠商利用 BT 技術的原因主要是想節省資源－－網絡資源。以前同一頻寬大概只能上載給有限的玩家，現在利用 BT 技術的話，上載數目基本上是無限的，只要使用者可以連上 BT 網絡，便可以由其他下載者（同時為上載者）中下載到所需要的資料。廠商便可以此提升這方面成本效益。

網絡電視會是另一種的商用途徑。沒有 BT 技術，網絡電視根本不可以發展。原因很簡單，電視（動畫影像）包含大量的資訊，現在的網絡大概可以承受少量的連接者，接收網絡電視視頻，但如果要做到好像普通利用大氣電磁波作媒介的電視一樣，同時可以被數以百萬的觀眾收看的話，就相當的不可能了。不過，只要利用 BT 技術，這種的分發量其實是可以實現的。網絡電視都可以做好像普通電腦一樣流暢的實時播放。

另外一種就是非即時的視頻。大陸開發的迅雷就屬於這一種。迅雷是利用 BT 技術加上 P2SP（Peer to Server and Peer）的模式分發視頻資料，不需要下載完畢都可以即時和流暢地觀看視頻。這也可能是將來的提供視頻的方式，即一種非即時的視頻。影像已經好像一些電視節目一樣，被預先錄影下來。當觀眾想要觀看的時候，就可以連上視頻網絡，只需要短時間的緩衝便可邊下載邊觀看。非即時視頻，好有可能是將來電視的替代品。試想想，你喜歡隨時隨地想看就看，還是喜歡限時限刻的要準時回家坐在電視機前？

網絡電視等技術會如何影響將來人類生活的發展，我也不知道。大概人類的生活會愈來愈離不開網絡。

[繼續閱讀]

[^ 縮回 ^]

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 的層面上。

[繼續閱讀]

[^ 縮回 ^]