BiglyBT 支援 BitTorrent v2

先前提到的「libtorrent 宣佈支援 BitTorrent v2」,BiglyBT 整合完了:「BiglyBT is the First Torrent Client to Support the BitTorrent V2 Spec」。

看了一下 BiglyBT 的介紹,主要是因為當初 https://en.wikipedia.org/wiki/Vuze 變成 adware 之後分支出來的:

BiglyBT is a feature filled, open source, ad-free, bittorrent client.

BiglyBT is the continuation of the Vuze/Azureus open source project first created in 2003, and is being actively developed by the original coders.

不過這是 Java 寫的 client,目前需求也不大,我自己應該還是會繼續等 qBittorrent 支援,看起來在這邊:「BitTorrent v2 #13344」,不過現在看起來沒什麼進展...

libtorrent 宣佈支援 BitTorrent v2

看到 libtorrent 宣佈支援 BitTorrent v2 (BEP 52) 的消息:「BitTorrent v2」。

BitTorrent v2 這個規格丟出來好久了,但一直都是 draft,而且沒什麼人想要理他,直到 Google 成功產生出 SHA-1 collision 的時候稍微有些音量跑出來,但沒想到居然有人跳下去支援了...

對使用者比較有感覺的差異是從 SHA-1 換成 SHA-2 的 SHA-256 了,這個會影響到整個 torrent file 的結構與 Magnet URI 的部份。

另外一個比較大的改變是 torrent 檔資料結構,有兩個比較大的改變。

第一個是以前用固定的 block size 切割,然後每個 block 產生出 hash,所以 torrent 檔會隨著 block size 選擇的大小 (成反比) 檔案大小 (成正比) 有關,現在會用 Merkle tree,所以只要有 root hash 就可以了。

第二個是以前是把所有檔案包在一起 hash,現在是個別檔案都有自己的 hash (改成 root hash),所以現在變成可以跨 torrent 檔共用檔案。

然後 libtorrent 的文章裡有提到向前相容的方法,不過以產品面上來說沒有什麼太大的誘因,libtorrent 雖然大,但其他幾家的支援度應該也是重點...

libtorrent 要支援 WebTorrent 協定了

一開始是看到「Libtorrent Adds WebTorrent Support, Expanding the Reach of Browser Torrenting」這篇,但看的時候發現裡面把 libtorrentlibTorrent 搞混 (這兩套不一樣,libTorrent 是 rTorrent 作者開發的),就暫時沒管這篇文章了...

剛剛看到「libtorrent adds support for the WebTorrent protocol」這篇,然後回頭去看本來 TorrentFreak 上的文章,發現已經拿掉本來提到的 rTorrent 了。(可以參考 Internet Archive 上的存檔資料 20200709223911)

WebTorrent 的支援對於 BitTorrent 社群算是很大的進展,主要是因為瀏覽器內就算用上 WebRTC 也沒有辦法模擬出 BitTorrent 的協定,所以只能調整協定,也就是這邊提到的 WebTorrent。

但訂了新的協定,最大的問題還是現有的 BitTorrent 程式都不支援 WebTorrent,所以沒辦法享用現有的 ecosystem,變成獨立的系統,對於推廣上面很不利...

而 libtorrent 算是第一個夠大的 library (對應到 client 的數量) 宣佈支援 WebTorrent,這樣用瀏覽器的人就會有更多機會透過 WebTorrent 協定對通了,接下來等更加發佈新版後應該就可以在 WebTorrent 上看到更多節點了...

最老的 BitTorrent 檔案

TorrentFreak 上看到 15 年前的 torrent,現在還活著:「World’s Oldest Torrent Still Alive After 15 Years」。

當年一開始出來的時候還是有 tracker 架構,不是完全的 p2p,但即使如此,對於當時檔案傳輸的幫助超大。現在在 bootstrap 後 (像是抓個前面提到的 fan-made torrent) 就可以靠 Peer exchangeDHT 達到 tracker-less 了。

而在遊戲界領域裡,Blizzard 也曾經採用了這個方式提供 patch 以降低伺服器端的頻寬壓力。不過後來好像是靠 CDN,就不用 P2P 的方式了?畢竟後來 CDN 競爭激烈不少,這類靜態檔案下載的技術大家都很成熟,對於有量的公司可以直接談個還不錯的價錢,而 P2P 還是有可能會受到干擾,走 HTTP (以及後來的 HTTPS) 還是遊戲公司的首選。

算是網路歷史上少數真正分散式的架構... 不會受到 vendor 喊停就不見。

直接在網頁上使用 WebTorrent

看到 GitHub 上的「mikeal/webtorrent-component」這個專案,可以很方便直接嵌入 BitTorrent 的資源,像是這樣嵌:

<script src="https://cdn.jsdelivr.net/npm/webtorrent-component@latest/dist/webtorrent-component.min.js"></script>

<web-torrent src="magnet:?xt=urn:btih:08ada5a7a6183aae1e09d831df6748d566095a10&dn=Sintel&tr=wss%3A%2F%2Ftracker.btorrent.xyz&tr=wss%3A%2F%2Ftracker.fastcast.nz&tr=wss%3A%2F%2Ftracker.openwebtorrent.com&ws=https%3A%2F%2Fwebtorrent.io%2Ftorrents%2F&xs=https%3A%2F%2Fwebtorrent.io%2Ftorrents%2Fsintel.torrent" file="Sintel.mp4" />

如果拿來跟「Using BitTorrent with Amazon S3」用的話可以在量大的時候省一些頻寬,並且在量小的時候還是維持有 seed (透過 Amazon S3 的服務做)。

Tails 3.0 出了,然後又開始提供 BitTorrent 下載了...

Tails 是個 Tor 的獨立環境,可以直接用 USB 開機或是透過虛擬機上線,避免受到其他干擾而洩漏資訊。

剛剛看到了 Tails 發佈 3.0 版的消息:「Tails 3.0 is out」,比較特別的是在下載頁面發現 BitTorrent 的下載方式又被放回去了。

前陣子本來在「BitTorrent 對 SHA-1 的改善計畫?」這邊有提到 Tails 的團隊因應 SHA-1 的問題,在討論是否要繼續提供 BitTorrent 的問題 (因為 BitTorrent 裡使用 SHA-1 做很多事情),當時的決議其實是暫時使用 BitTorrent 發佈:「Biterrant attack」。

不過後續的更新這樣寫,所以看起來暫時會先恢復 BitTorrent 下載的方式:

After reading this discussion, my current conclusion is that we've totally misunderstood the impact of the attack, and that the security of our bittorrent downloads is still good enough. So I propose we revert to what we did before the 2.12 release, i.e. ship Torrents, for the foreseeable future when 2nd pre-image attacks are not realistic yet.

回到 Tails 3.0 本身,其中比較大的改變是放棄了 32bits 的支援:

Tails 3.0 works on 64-bit computers only and not on 32-bit computers anymore.

然後以前要在開機進到進階選單才有的語言設定,現在變成預設就會提醒了:

也許該再來測試看看注音輸入法好不好用的問題了 XD

BitTorrent 對 SHA-1 的改善計畫?

最新一版的 Tails 不再支援透過 BitTorrent 下載,會被導去「Biterrant attack」這邊的連結,裡面有一些關於在 SHA-1 打穿後要怎麼判斷。

BitTorrent 的討論 (包括 BitTorrent 發明人 Bram Cohen 的參與) 則是在 GitHub 上:「Transitioning to stronger hash function · Issue #58 · bittorrent/bittorrent.org」,不過看起來連要用什麼 hash algorithm 的定案都還沒有啊... 而且二月底比較熱鬧一點,三月後都沒什麼動作了。

看起來短時間也不會有動作了...

把 rTorrent 跑到 Docker 裡

花了些時間研究如何把 rTorrent 丟進 Docker 裡跑,對應的設定都放在 GitHub 上的「gslin/rtorrent-docker」這邊。

使用的方式是傳入使用者的 uid 與 gid (-e USER_GID-e USER_UID),以及預期的 port (有兩個地方,一個是 -e PORT,另外一個是 -p 開 port forwarding,不然外面沒辦法直接連進來),然後把 TERM 變數丟進確保 console 的操作。剩下來把對應的目錄掛進 container 讓他可以寫入 (-v 的部份):

docker run \
    -e PORT=6991 -e TERM=${TERM} \
    -e USER_GID=`id -g` -e USER_UID=`id -u` \
    -i -p 6991:6991 -t -v "`pwd`:/srv/rtorrent" \
    gslin/rtorrent:latest

自己用這樣應該是夠用了... 把這串命令放到 shell 的 alias 裡面用就好了。

印度 ISP 跟 Torrent 站台合作加速下載

在「Indian ISPs Speed Up BitTorrent by ‘Peering’ With a Torrent Site」這篇講到印度的 ISP 跟 torrent 站台 TorBox 合作,加速下載的速度。

裡面提到了蠻有趣的加速技巧:

They help users to download content faster by linking them to local peers in their own network.

不知道是不是指 Local Peer Discovery (BEP-14) 的技術,如果是的話大概可以猜出作法... 這樣可以降低不少 ISP 對外頻寬的流量與成本。

拿 Openvirtuals 的主機跑 Syncthing...

Low End Box 上逛到的主機商 Openvirtuals,在 LEB 上看到的優惠已經沒了,但點進去後看到 Buffalo 的主機年繳有 50% off,加上硬碟空間又大,就決定弄一台玩玩...

SSD-CACHED 的 Mini 是 256MB RAM + 512MB vSwap 以及 90GB 空間,要 USD$16/year,而 Standard 的都是兩倍,但只要 USD$20/year,就決定買 Standard 了...

後台的功能比想像中完整,這是系統資訊與狀態的畫面,功能其實不比 DigitalOcean 差 (不過畫面就普普通通了):

裝了 Ubuntu 14.04 64bits 跑,不過 Linux kernel 偏舊了點,是 2.6.32,查了一下維基百科上的資料,應該是 2009 年底的版本,是目前唯一一個 2.6 上有繼續維護的版本:

Linux two 2.6.32-042stab108.2 #1 SMP Tue May 12 18:07:50 MSK 2015 x86_64 x86_64 x86_64 GNU/Linux

網路的部份,實際測試時發現不是很穩定,HiNet 過去有時候會有不低的 packet loss,可能是中間有線路因為 DDoS 造成不穩定。

反正只是要跑 Synthing 也還好,就先這樣丟著... 上面順便跑個 rtorrent 幫忙 Ubuntu 分擔 ISO Image。