一支程式，三種傳輸

BitComet 是免費的下載管理程式，把 BT、HTTP 與 FTP 收在同一個佇列裡。這裡寫的版本是 2.22。把三者放在一起聽起來只是方便，實際上正是這支程式存在的理由：同一個檔案可能同時有兩條路可走，而只認得其中一種的管理程式，會逼使用戶在還不知道哪條路比較快之前就先做選擇。

平常的情況更無聊也更常見。一個專案的發行說明走 HTTP，一個大封裝走 BT，公司網路裡的鏡像站只有 FTP 進得去。一份清單、一組限速、一個看得到進度的地方。

群體（swarm）後面的機制

BT 那一半照協議走，而不是自己發明一套。傳輸從種子檔或磁力連結開始，資料是跟其他參與者交換來的，不是從單一伺服器拿下來的。同一個 swarm 裡的每個人同時下載也同時上傳 —— 這就是為什麼熱門的傳輸可以比任何單一伺服器能提供的還快，而冷門的傳輸可以接近停擺。

這是機制描述，不是關於「該傳什麼」的主張。協議對內容是中立的，用戶端也是；一個 swarm 能跑多快，取決於有多少人手上還留著它。

九十九% 的問題

這個設計的弱點在傳輸的尾巴。如果持有最後幾塊的參與者都走了，下載就停在九十九%，而且一直停在那裡 —— 檔案不能用、空間還佔著，介面上也沒有任何地方解釋為什麼。

長效種子處理的正是這件事。出現過的區塊會被保留下來，活得比「剛好持有它的那些 peer」更久，所以本來會卡住的傳輸有個地方可以收尾。同一個機制通常更早就以速度的形式出現：背後有長效來源的傳輸，不必等到某個方便的時間點湊齊足夠的 peer 才能開始跑。

透過快取寫入

磁碟快取是最看不見的功能，也是後果最長的一個。一次下載是幾千次分散的小寫入，散落在一個還在拼裝的檔案上；直接寫，這種模式會讓硬碟忙著換軌，對它也吃力。把區塊先收在記憶體裡，再以較大、有序的批次寫出去，可以減少讀寫次數 —— 這就是這支程式的主張：減少磨損，而不是提高速度。

它也解釋了一個用戶會注意到的現象：任務顯示完成之前的最後幾秒，有時候是在寫入，而不是在接收。

影片還在下載就先播

常被叫做「邊下邊放」的功能，取決於一個決定：先抓媒體檔的開頭與結尾。開頭是播放器起播需要的，結尾則放著許多封裝格式擺在那裡的索引；兩邊都到手，中間還在傳的時候就可以開始播。少了尾巴，堅持先讀索引的播放器不管你中間到了多少，都會拒絕開始。

它站在哪裡

BitComet 不是開源專案，也沒有這樣宣稱；它免費，而且是為「整天開著佇列」的人做的，不是為一個月抓一個檔案的人做的。老實的總結是：三種協議的支援、長效種子、以及在下載途中播放，這三件事決定了它合不合用 —— 如果工作裡混著不同的路線，而且有幾個大到不能死在九十九% 的傳輸，那就是這支程式的用途。