Về hệ thống BitTorrent trên Linux (1)


1)

Kể từ khi ra đời tới nay thì giao thức 12 năm tuổi BitTorrent cho dù bị ngăn chặn, chỉ trích bởi các ISP và các đơn vị cung cấp nội dung số thì đây vẫn là một trong các giao thức phổ biến với bằng chứng là có hằng trăm triệu có người dùng với lưu lượng phát sinh từ nó chiếm tới 43% – 70% tổng lưu lượng trên Internet [1]. BitTorrent được thiết kế để thích hợp với nhu cầu chia sẻ các file kích thước lớn với lượng người tải đồng thời cao, càng nhiều người tải cùng lúc thì thì thời gian tải xong file càng được rút ngắn.

Ngoài những vấn đề cơ bản như tracker, seeder/leecher, torrent, share ratio,… mà dường như ai cũng biết thì BitTorrent có một đặc tả mà có thể ít người quan tâm là Web Seeding. Nếu client có hỗ trợ thì tính năng này thì các peer có thể cùng lúc dùng cả HTTP và BitTorrent để tải về một source, ví dụ, 13/20 mảnh của source được tải về từ Webserver, 7/20 mảnh còn lại được tải về từ các seeder/leecher trong swarm. Và như vậy, nếu lượng peer trong swarm ít hay các seeder ngưng hoạt động thì vẫn còn đường HTTP làm dự phòng và ngược lại.

Mọi người thường biết tới BitTorrent thông qua các website mà thực chất là các torrent indexer nổi tiếng trên thế giới như The Pirate Bay hay các forum chia sẻ các HD content, software,… Nhưng gần đây tôi biết thêm được là nó còn được dùng bởi các công ty công nghệ lớn như Facebook, Twitter nhằm tận dụng lợi thế chia sẻ phân tán của BitTorrent trong quá trình code deployment cùng lúc cho hàng ngàn server của họ [2]. Hơn thế, cha đẻ của protocol này còn định làm một cuộc cách mạng trong công nghệ live streaming trên nền BitTorrent, chi tiết về cái này có thể xem thêm ở link [3].

2)

Nhu cầu giả định ở đây là xây dựng một hệ thống phân phối nội dung có kích thước lớn cho hàng ngàn người tải cùng lúc dùng BitTorrent kết hợp HTTP Seeding làm giao thức truyền tải với các đòi hỏi cụ thể như:

– Toàn bộ các thành phần gồm tracker, seeder sẽ chạy trên Linux (text-based).

– Với Tracker thì:

+ Sẽ là dạng private tracker, tự quản lý và chỉ phục vụ cho các torrent mà mình muốn phân phối cho người dùng.

+ Ngoài HTTP thì hỗ trợ UDP được thì càng tốt do lợi điểm của UDP so với TCP (mà HTTP dựa trên nó).

+ Giao diện giúp theo dõi và thống kê hoạt động (càng chi tiết càng tốt) của các torrent để phục vụ cho mục đích tạo báo cáo về sau như: lượng completed download, thông tin về seeder/leecher (IP, port, percent finished,…).

+ Cho phép tạo các nhóm quản trị như admin, viewer.

+ Ổn định và hiệu suất, có khả năng mở rộng dễ dàng bằng các plug-in có sẵn hay tự code thêm nếu cần.

– Với Seeder thì:

+ Đáp ứng đầy đủ các tính năng cần có của một BitTorrent client thông thường như: cache, encryption, DHT, PEX, prioritizing, bandwidth throttling, UDP tracker.

+ Vì là server-side nên cần có thêm tính gọn nhẹ, hiệu suất (RAM, CPU, disk usage thế nào), và nếu làm tốt cơ chế super-seeding thì càng tốt.

+ Mục logging và statistic cần chi tiết một chút.

+ Hỗ trợ authorization nếu có nhiều nhóm user/product chạy trên cùng một seeder.

– Ngoài ra thì cũng không thể chọn thành phần đã quá lâu rồi không còn được liên tục phát triển để thích ứng với các tiêu chuẩn mới cho BitTorrent như uTP, magnetlink, DHT.

3)

Với các đòi hỏi như trên thì dạo qua Wikipedia [4], [5] sẽ có được một số ứng viên (đều open source cả) là:

(Phần nêu ưu điểm và hạn chế dưới đây được hình thành dựa theo nhu cầu ở mục 2)).

[+] Tracker:

* RivetTracker

– Ưu điểm:

+ Web-based, user-friendly, easy of use, detailed statistic, role-based authorization.

+ Customisable (PHP code).

– Hạn chế:

+ Cần hiểu biết về LAMP stack nếu muốn optimize và scale cho lượng lớn người dùng cùng lúc.

+ 3 năm rồi chưa được cập nhật gì mấy, ẩn chứa rủi ro về security nên cần xem xét kỹ khi dùng.

* OpenTracker

 – Ưu điểm:

+ 4/5 public tracker trên thế giới dùng nó [6]. Hỗ trợ UDP, IPv6.

+ Chạy hoàn toàn trong RAM, hiệu năng cao, tốn ít tài nguyên.

– Hạn chế:

+ Khó tùy biến nếu không rành về lập trình hệ thống trên C/C++.

+ Phần logging, statistic hay authorization là không có.

[+] Seeder:

* rTorrent

 – Ưu điểm:

+ Viết bằng C++ và focus của tác giả là high performance và good code.

+ Hỗ trợ super-seeding. Nhiều plug-in và có thể control qua XML-RPC over SCGI hay giao diện CLI cũng dễ xài.

– Hạn chế:

+ Khi sửa file config thì phải restart lại chứ không cho reload.

+ Phần logging khá hạn chế, không có authorization nhưng có API và source code rồi, vấn đề là thời gian và con người để tùy biến chúng.

* Transmission

 – Ưu điểm:

+ Tốn ít tài nguyên. Có dạng daemon thích hợp cho server và các embedded system.

+ Liên tục phát triển, hỗ trợ các chuẩn mới như uTP.

– Hạn chế:

+ Khá ức chế khi bị giới hạn số socket/connection ở mức 1024 mặc dù đã chỉnh max connected peers vượt quá 1000 dẫn đến thông báo lỗi “unable to save resume file too many open files”. Điều này được lý giải do Transmission sử dụng libcurl nên phụ thuộc vào ngưỡng an toàn của library này. Sẽ cần phải tìm hiểu và chỉnh lại vấn đề này.

+ Cũng không có cơ chế authorization khi cần seeding cho các group/product khác nhau.

* Vuze

 – Ưu điểm:

+ Nhiều feature, plug-in vượt trội tới mức dư thừa.

+ Logging và detail statistic đầy đủ.

+ Console/Web/Desktop UI, authorization đều có.

– Hạn chế:

+ Nền Java và ôm đồm nhiều thứ nên chạy khá nặng

+ Không biết tại làm sao mà bản trên Linux, cài dạng daemon thì không thể thay đổi configuration được –> các setting về min/max số peer/upload slot không được apply.

4) Một số vấn đề khi triển khai, vận hành

Phần này cũng phát sinh nhiều vấn đề không kém bước thử nghiệm, đánh giá và chọn ra các thành phần phù hợp.

Thứ nhất: đảm bảo tính high availability cho tracker

Một khi đã quyết định tự làm private tracker thì đây trở thành critical point của toàn bộ hệ thống BitTorrent. Trái với phần seeder, khi chết con này thì có thể còn các seed/leecher khác chia sẻ các mảnh cho nhau thì nếu tracker không hoạt động được thì các peer không còn đầu mối để cập nhật thông tin và tìm tới các peer khác nữa. Do vậy, để tăng tính HA cho private tracker thì cần xem xét áp dụng một số biện pháp sau:

– Nếu là HTTP tracker thì có thể dùng một load balancer như HAProxy để chia request cho hai hoặc nhiều webserver làm tracker đứng ở sau. Còn nếu là UDP tracker thì có thể dùng DNS round robin. Cũng cần lưu ý việc đồng bộ database của các tracker dùng cơ chế master-master để khi các peer nói chuyện với bất kỳ tracker nào thì đều nhận về thông tin được cập nhật và nhất quán.

– Kích hoạt DHT trên seeder sẽ giúp các peer mà cũng có dùng DHT song song với private tracker có thể tìm được thông tin về các peer khác ngay cả khi private tracker ngưng hoạt động. Điều này cực kỳ hữu ích tuy rằng việc cập nhật từ DHT sẽ chậm hơn so với private tracker.

– Bổ sung thêm các public tracker như OpenBittorrent, PublicBittorrent vào file .torrent. Việc làm này cũng khá hiệu quả dù rằng đa số các phần mềm client đều ưu tiên dùng các public tracker hơn là private tracker và do vậy sẽ mất đi các thông số thông kê vì các peer không còn gửi báo cáo về cho private tracker nữa.

* Tham khảo

[1] http://en.wikipedia.org/wiki/BitTorrent

[2] https://blog.twitter.com/2010/murder-fast-datacenter-code-deploys-using-bittorrent

[3] http://torrentfreak.com/bittorrent-s-bram-cohen-patents-revolutionary-live-streaming-protocol-130326/

[4] https://en.wikipedia.org/wiki/Comparison_of_BitTorrent_clients

[5] http://en.wikipedia.org/wiki/Comparison_of_BitTorrent_tracker_software[6] http://torrentfreak.com/the-worlds-5-largest-public-bittorrent-trackers-100614/

-mt.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s