Elixirで書かれた新しいBitTorrentトラッカー実装
(github.com/Dahrkael)- ExTracker は、Elixirベースの新しい BitTorrentトラッカープロジェクト
- 高性能 と 低メモリ使用量 を基盤に設計されており、事実上ゼロセットアップですぐに利用可能
- BitTorrentプロトコル（BEP） の複数の拡張提案をサポートし、多様性と互換性を提供
- HTTPS対応、ディスクバックアップ、運用管理機能 など、実務に必要な主要機能を含む
- 現時点では 産業用途には未完成 の段階だが、テストインスタンスは実運用中
概要とプロジェクトの重要性
ExTracker は Elixir で実装された新しい BitTorrentトラッカー のオープンソースプロジェクトで、既存のトラッカーと比べて次のような利点を提供する
- 最新の Erlang/Elixir ランタイム を基盤とし、マルチコアをすべて活用する高性能な構造を持つ
- 大規模なピア環境（約100万ピアあたり 200MB RAM）で 低メモリ使用量 を保証
- 複雑な事前設定なしで 即座に動作 するゼロセットアップ環境を提供
- 複数の BitTorrent Enhancement Proposal（BEP） をサポートし、最新のトラッカー標準との互換性を維持
既存のトラッカーに比べて 軽量かつ効率的 であり、Elixir固有の並行処理および分散環境サポートを最大限に活用することで、同種のオープンソースプロジェクトとの差別化を図っている
主な機能 (Features)
- 高性能: すべての CPU コアを活用、インメモリストレージを使用
- メモリ最適化: 100万ピアあたり約 200MB RAM を使用
- ゼロセットアップ: 追加設定なしですぐに実行可能
サポートする BitTorrent Enhancement Proposals (BEP)
- BEP 0: BitTorrentプロトコル仕様に準拠
- BEP 15: UDPトラッカープロトコルをサポート
- BEP 23: 圧縮されたピアリストを返却
- BEP 7: IPv6トラッカー拡張
- BEP 24: 外部 IP を返却
- BEP 41: UDPトラッカープロトコル拡張
- BEP 48: Scrapeトラッカー拡張（部分サポート）
- BEP 52: BitTorrentプロトコル v2
- 一部機能（BEP 27、21、31 など）は未実装、または計画中
- BEP 8（トラッカーピア難読化）はサポートしない
その他の機能
- HTTPS接続対応
- ディスクバックアップ（データ安全性の強化）
- （予定）Infohash ホワイトリスト/ブラックリスト管理
- （予定）ピア管理: 権限、定期クリーンアップ、排除 など
- （予定）メトリクス/指標管理 および GeoIP 活用
- WebTorrent をサポートする予定はない
ユーザー/開発者からの提案は Issue として受け付けている
実行方法
- ソースコードを直接実行
- Erlang および Elixir が必要
- リポジトリをクローン後、環境設定して実行
- リリース方式
- 公式リリースはないが、直接ビルドおよび配布する方式をサポート
- リリースファイルをコピーし、環境設定後に実行
- Docker
- 公式コンテナイメージを利用可能
docker-composeのサンプルファイルを提供- コンテナ内部の設定には環境変数の利用を推奨
著作権およびライセンス
- Copyright (c) Dahrkael <dahrkael at outlook dot com>
- Apache License 2.0 の下で配布
- ライセンスの詳細はリポジトリの LICENSE ファイルを参照
1件のコメント
Hacker News のコメント
OTP 中心の設計を期待していたが、実際のコードはほとんど手続き的で、ETS や Application のような ETS ベースのシステムを毎回直接扱っている点が惜しいという感想。
作者が Elixir や BEAM 言語でのサービス設計を学びたいなら、James Edward Gray と Bruce Tate の "Designing Elixir Systems with OTP"、そして Lance Halvorsen の "Functional Web Development with Elixir, OTP, and Phoenix" を参考書として勧める。
トレントトラッカーは結局のところ特化型データベースなので、できるだけ高速にデータを処理することが最重要目標だと考えている。
それでも勧めてもらった本はぜひ読むつもりだと述べている。
C++ 開発者には Go と Elixir を好きになる何か特別なものがあると思う。
自分自身もその一人だ。
性能に惹かれて C++ を好む人たちが、Go や Elixir のマルチスレッド性能を愛するようになるという話。
素晴らしいプロジェクトだという好意的な意見。
パターンマッチングがほとんどの分岐やコードの複雑さを減らしてくれるので、コードがずっときれいになるのが利点だ。
Let it crashの哲学のおかげで大半の例外ケースを無視しても、実際に問題が起きたとしても影響が 1 クライアントに限定されると確信できる。10 年以上 Elixir で運用してきたアプリで予期しないダウンタイムを経験したことがない。
保守やアップデートを除けば常に 100% 稼働率だったことを強調している。
顧客には「Python や Go ではなく Elixir で作ったサービスは絶対に落ちないうえに、素敵なダッシュボードも提供できる」と売り込み、実際に多くの人がすぐ納得すると話している。
Elixir のように struct と enum、そして関数シグネチャでのパターンマッチングをサポートするシステム言語があればいいのにと思う。
自分も BT（BitTorrent）学習目的で TypeScript で似たようなものを作ったことがある。
その後 Rust で再実装しながら Rust も学んだ。
自分のプロジェクトへのリンク
自分はデータベースに単純に redis を使ったが、相手はすべてをメモリ上に載せて使っている点が興味深い。
こう設計するにあたって悩みや面白い判断、問題点などがあったのか気になる。
ちなみに redis ベースの自分の解決策では、announce を何度も行うと peer が常にランダムに混ざるわけではないという問題がある。
各ピアのデータをそれぞれのプロセスで並行して読み書きできるため、競合とレイテンシが最小限に抑えられる。
唯一逐次的になるのは新しい swarm が最初に作られるときだけで、頻繁に起きることではないので問題ない。
残念ながらテーブルからランダムに行を取り出すネイティブサポートがないため、今は swarm 全体を読み込んでからランダムな部分集合を自分で選んでいる。
関連コード例
素晴らしいプロジェクトだと思う。
以前、自分も Elixir で基本的なトラッカーを作ったことがある。
自分のコードへのリンク
特に private tracker として実装した理由が気になる。
プロジェクト公開おめでとう。
opentracker と比べてどう動くのか、性能などの詳しい情報が気になる。
しかし extracker は CPU コア数が 2 桁になるあたりで真価を発揮する。
まだきちんとしたベンチマークは実施していない。
とてもよく作られたプロジェクトだという称賛。
簡単な助言として、
IO.putsの代わりに Logger に移し、OTel の追加も検討するとよいのではという意見。これには同意する。
組み込みの Logger と Telemetry アプリケーションだけでも十分だという意見。
今後 opentelemetry やほかのものも Telemetry フックに簡単に追加できる。
Logger documentation
Telemetry documentation
好みの otel sink（メトリクスの送信先）は何かという質問。
Elixir が本当に大好きだという気持ち。
今、素晴らしい notification engine を Elixir で開発している。
Elixir は本当に卓越しているという感嘆。
private プロジェクトなのか、それとも OSS（オープンソース）なのか気になる。
Elixir エコシステムには、より良い notification engine が必要な状況だ。
参考にしたプロジェクトはあるのか。
開発にはどれくらいかかったのか。
qbittorrent と比べると、どの程度の機能が動くのか気になる。
別のプロジェクトで使うトラッカーが必要で始めたが、トラッカー開発自体のほうが面白くなって続けている。
他のトラッカーのコードは参考にしたが、たいてい複雑すぎるか単純すぎるかで、あまり参考にならなかった。
ここまで、複数回の徹夜コーディングを経て 3 か月開発している。
qbittorrent のようなクライアントではないが、今後は seedbox 向けクライアントのプロジェクト案もある。
トラッカーはトレントクライアントではないという説明。
実際に使ってみたが、HTTPS が正しく動作しない問題に遭遇した。
また、コンソールに
04:43:20.160 [warning] invalid 'event' parameter: size: 6 value: "paused"
という警告メッセージが出続けていた。
それでも動作自体はしているようだ。
HTTP の統計も見たかったが、UDP の統計しか確認できなかった。
（自分は UDP を無効化している。）
"paused"イベントは BEP 21 の一部で、クライアントがまだ完了していないが、もうダウンロードしていないことをトラッカーに伝えるためのものだ。たとえば、ユーザーがトレント内の一部ファイルだけを欲しい場合に使われる。
そのプロジェクトの readme には BEP 21 非対応であることが明記されている。
HTTP 関連の Telemetry はまだ ToDo リストにある。
Web サーバーとして 3rd-party ライブラリを使っているので、適切な連携方法をさらに検討中だ。
HTTPS を使うには
:https_keyfileに有効な証明書のパスを指定する必要がある。現時点では HTTPS が必要なら、トラッカーの前段に Caddy や Nginx を置くことを勧める。
certbot 連携も計画しているが、大半のトレントピアは UDP を使うため優先度は低い。
本当に素晴らしいプロジェクトだという称賛。
Elixir をメイン言語として使うつもりがあるのかという質問。
Elixir は有力な選択肢の一つだという返答。
個人的には C++ よりも確実に楽しく働けるだろうと確信している。
自分はそうではないが、9 年 2 か月近く Elixir で働いており、Rust と Golang も扱えるという自己紹介。
現時点で誰か採用中なのか気になっている。