Neue in Elixir geschriebene Implementierung eines BitTorrent-Trackers

(github.com/Dahrkael)

2 Punkte von GN⁺ 2025-06-20 | 1 Kommentare | Auf WhatsApp teilen

ExTracker ist ein neues BitTorrent-Tracker-Projekt auf Basis von Elixir
Es wurde für hohe Leistung und geringen Speicherverbrauch konzipiert und ist praktisch mit Zero-Setup sofort einsatzbereit
Es unterstützt verschiedene Erweiterungsvorschläge des BitTorrent-Protokolls (BEP) und bietet damit Vielfalt und Kompatibilität
Es umfasst wichtige praxisrelevante Funktionen wie HTTPS-Unterstützung, Festplatten-Backups und Betriebsverwaltungsfunktionen
Derzeit ist es für den industriellen Einsatz noch nicht vollständig ausgereift, aber eine Testinstanz läuft bereits im echten Betrieb

Überblick und Bedeutung des Projekts

ExTracker ist ein neues Open-Source-Projekt für einen in Elixir implementierten BitTorrent-Tracker und bietet gegenüber bestehenden Trackern die folgenden Vorteile

Basierend auf der modernen Erlang/Elixir-Runtime verfügt es über eine Hochleistungsarchitektur, die alle Multicore-Ressourcen nutzt
In großen Peer-Umgebungen garantiert es geringen Speicherverbrauch (ca. 200 MB RAM pro 1 Million Peers)
Es bietet eine Zero-Setup-Umgebung, die sofort funktioniert, ohne komplexe Vorkonfiguration
Durch Unterstützung mehrerer BitTorrent Enhancement Proposals (BEP) bleibt es mit aktuellen Tracker-Standards kompatibel

Im Vergleich zu bestehenden Trackern ist es leichtgewichtig und effizient und hebt sich von Open-Source-Projekten derselben Klasse ab, indem es die für Elixir typische Unterstützung für Nebenläufigkeit und verteilte Umgebungen maximal nutzt

Hauptfunktionen (Features)

Hohe Leistung: nutzt alle CPU-Kerne, verwendet In-Memory-Speicher
Speicheroptimierung: etwa 200 MB RAM pro 1 Million Peers
Zero-Setup: sofort ohne zusätzliche Konfiguration ausführbar

Unterstützte BitTorrent Enhancement Proposals (BEP)

BEP 0: Einhaltung der BitTorrent-Protokollspezifikation
BEP 15: Unterstützung für das UDP-Tracker-Protokoll
BEP 23: Rückgabe einer kompakten Peerliste
BEP 7: IPv6-Tracker-Erweiterung
BEP 24: Rückgabe externer IPs
BEP 41: Erweiterung des UDP-Tracker-Protokolls
BEP 48: Scrape-Tracker-Erweiterung (teilweise unterstützt)
BEP 52: BitTorrent-Protokoll v2
Einige Funktionen (BEP 27, 21, 31 usw.) sind noch nicht implementiert oder in Planung
BEP 8 (Tracker Peer Obfuscation) wird nicht unterstützt

Weitere Funktionen

Unterstützung für HTTPS-Verbindungen
Festplatten-Backups (zur Verbesserung der Datensicherheit)
(Geplant) Verwaltung von Infohash-Whitelist/Blacklist
(Geplant) Peer-Verwaltung: Berechtigungen, regelmäßige Bereinigung, Ausschluss usw.
(Geplant) Metrik-/Kennzahlenverwaltung und Nutzung von GeoIP
Unterstützung für WebTorrent ist nicht geplant

Vorschläge von Nutzern/Entwicklern werden als Issues entgegengenommen

Ausführung

Direkt aus dem Quellcode ausführen
- Erlang und Elixir erforderlich
- Repository klonen, konfigurieren und ausführen
Release-Modus
- Es gibt keine offiziellen Releases, aber direktes Bauen und Verteilen wird unterstützt
- Release-Dateien kopieren, konfigurieren und ausführen
Docker
- Offizielles Container-Image verfügbar
- Beispieldatei für docker-compose wird bereitgestellt
- Für die Konfiguration im Container wird die Nutzung von Umgebungsvariablen empfohlen

Urheberrecht und Lizenz

Copyright (c) Dahrkael <dahrkael at outlook dot com>
Veröffentlicht unter der Apache License 2.0
Details zur Lizenz siehe Datei LICENSE im Repository

1 Kommentare

GN⁺ 2025-06-20

Hacker-News-Kommentare

Jemand bedauert, dass er ein OTP-zentriertes Design erwartet hatte, der tatsächliche Code aber fast prozedural sei und ETS oder ETS-basierte Systeme wie Application jedes Mal direkt behandle.
Falls der Autor lernen wolle, wie man Services in Elixir oder BEAM-Sprachen entwirft, empfiehlt er als Referenzbücher Designing Elixir Systems with OTP von James Edward Gray und Bruce Tate sowie Functional Web Development with Elixir, OTP, and Phoenix von Lance Halvorsen.
- Beim ersten Versuch sei es im OTP-Stil geschrieben gewesen, aber bei diesem konkreten Ablauf habe sich gezeigt, dass sich die gleiche Skalierbarkeit nicht unbedingt ergebe.
  Ein Torrent-Tracker sei letztlich eine spezialisierte Datenbank, daher sei das wichtigste Ziel, Daten so schnell wie möglich zu verarbeiten.
  Die empfohlenen Bücher wolle er trotzdem unbedingt lesen.
Es gebe wohl irgendetwas Besonderes, das C++-Entwickler an Go und Elixir mögen lasse.
Er selbst gehöre auch dazu.
Leute, die C++ wegen der Performance mögen, würden die Multithreading-Performance von Go oder Elixir lieben.
Außerdem ein positives Fazit: ein cooles Projekt.
- Zu C++-Entwicklern könne er nicht viel sagen, aber Erlang/Elixir seien dank ihrer Implementierung von Pattern Matching extrem stark beim Parsen von Protokollen.
  Pattern Matching reduziere den Großteil von Verzweigungen und Codekomplexität, wodurch der Code viel sauberer werde.
  Dank der Philosophie „Let it crash“ könne man die meisten Ausnahmefälle ignorieren und trotzdem sicher sein, dass ein tatsächliches Problem nur einen einzelnen Client betreffe.
  In über zehn Jahren mit in Elixir deployten Apps habe er nie unerwartete Downtime erlebt.
  Abgesehen von Wartung und Updates seien sie immer bei 100 % Verfügbarkeit gewesen.
  Gegenüber Kunden werbe er damit, dass ein in Elixir statt in Python oder Go gebauter Service nicht nur nie abstürze, sondern auch ein großartiges Dashboard biete, und viele ließen sich sofort überzeugen.
  Er würde sich eine Systemsprache wünschen, die wie Elixir struct, enum und Pattern Matching in Funktionssignaturen unterstützt.
Er selbst habe zu Lernzwecken rund um BT (BitTorrent) schon einmal etwas Ähnliches in Typescript gebaut.
Danach habe er es in Rust neu implementiert und dabei auch Rust gelernt.
Link zu meinem Projekt
Er habe einfach Redis als Datenbank verwendet, finde es aber interessant, dass die andere Lösung alles vollständig im Speicher halte.
Er fragt, ob es bei diesem Design Überlegungen, interessante Entscheidungen oder Probleme gab.
Seine Redis-basierte Lösung habe übrigens das Problem, dass Peers bei mehreren announce-Aufrufen nicht immer zufällig durchmischt würden.
- Nach seiner Erfahrung sei In-Memory-ETS die beste Wahl.
  Die Daten jedes Peers könnten in separaten Prozessen gleichzeitig gelesen und geschrieben werden, wodurch Konkurrenz und Latenz minimal blieben.
  Der einzige wirklich serielle Teil sei der Moment, in dem ein neuer Swarm zum ersten Mal erzeugt werde; das passiere aber nicht oft und sei daher in Ordnung.
  Leider gebe es keine native Unterstützung dafür, zufällige Zeilen aus einer Tabelle zu ziehen, daher werde aktuell der gesamte Swarm geladen und daraus manuell eine zufällige Teilmenge ausgewählt.
  Relevantes Codebeispiel
Tolles Projekt.
Früher habe er selbst auch einmal einen einfachen Tracker in Elixir gebaut.
Link zu meinem Code
- Klingt interessant.
  Er fragt insbesondere, warum es als Private Tracker umgesetzt wurde.
Glückwunsch zum Release des Projekts.
Er würde gern mehr dazu wissen, wie es im Vergleich zu opentracker arbeitet und wie die Performance aussieht.
- Für kleine Tracker sei opentracker vermutlich schneller und brauche auch weniger Speicher.
  Extracker spiele seine Stärke aber aus, wenn die Zahl der CPU-Kerne in den zweistelligen Bereich gehe.
  Ordentliche Benchmarks habe er bisher noch nicht durchgeführt.
Lob für ein sehr gut gemachtes Projekt.
Einfacher Tipp: statt IO.puts lieber Logger verwenden und vielleicht auch OTel ergänzen.
- Zustimmung dazu.
  Schon mit der eingebauten Logger- und Telemetry-Applikation komme man weit genug.
  Später lasse sich opentelemetry oder auch anderes leicht über Telemetry-Hooks ergänzen.
  Logger-Dokumentation
  Telemetry-Dokumentation
- Frage nach dem bevorzugten otel sink, also wohin die Metriken gesendet werden sollen.
Er mag Elixir wirklich sehr.
Gerade entwickle er eine coole Notification-Engine in Elixir.
Elixir sei wirklich herausragend.
- Zustimmung, das sei cool.
  Er fragt, ob es ein privates Projekt oder OSS (Open Source) sei.
  Das Elixir-Ökosystem brauche eine bessere Notification-Engine.
- Wie es angefangen hat.
Ob es Projekte gab, an denen man sich orientiert hat.
Wie lange die Entwicklung gedauert hat.
Und wie viel im Vergleich zu qBittorrent funktioniere.
- Es habe angefangen, weil er einen Tracker für ein anderes Projekt brauchte, aber die Tracker-Entwicklung selbst habe dann mehr Spaß gemacht, sodass er dabeiblieb.
  Er habe sich schon anderen Tracker-Code angesehen, aber das meiste sei entweder zu komplex oder zu simpel gewesen und daher als Referenz wenig geeignet.
  Bisher stecke in dem Projekt eine Entwicklung über drei Monate hinweg mit mehreren Nächten durchprogrammieren.
  Es sei kein Client wie qBittorrent, aber er habe künftig auch eine Idee für ein auf Seedboxen ausgerichtetes Client-Projekt.
- Erklärung, dass ein Tracker kein Torrent-Client ist.
Er habe es selbst ausprobiert, dabei aber das Problem gehabt, dass HTTPS nicht richtig funktionierte.
Außerdem sei auf der Konsole ständig die Warnung
04:43:20.160 [warning] invalid 'event' parameter: size: 6 value: "paused"
ausgegeben worden.
Trotzdem scheine es zu funktionieren.
Er hätte sich auch HTTP-Statistiken ansehen wollen, habe aber nur UDP-Statistiken sehen können.
(UDP hatte er selbst deaktiviert.)
- Das paused-Event sei Teil von BEP 21 und diene dazu, dem Tracker mitzuteilen, dass ein Client zwar noch nicht fertig sei, aber nicht weiter herunterlade.
  Das sei zum Beispiel nützlich, wenn ein Nutzer nur bestimmte Dateien eines Torrents wolle.
  Im README des Projekts sei vermerkt, dass BEP 21 nicht unterstützt werde.
- HTTP-bezogenes Telemetry stehe noch auf der ToDo-Liste.
  Da als Webserver eine Third-Party-Library verwendet werde, denke er noch darüber nach, wie sich das am besten integrieren lasse.
  Für HTTPS müsse man unter :https_keyfile einen gültigen Zertifikatspfad angeben.
  Wenn man HTTPS wolle, empfehle er derzeit, vor den Tracker Caddy oder Nginx zu setzen.
  Eine certbot-Integration sei ebenfalls geplant, habe aber geringe Priorität, weil die meisten Torrent-Peers UDP nutzten.
Erneutes Lob für ein wirklich cooles Projekt.
Frage, ob Elixir als Hauptsprache infrage komme.
- Antwort: Elixir sei eine der Hauptoptionen.
  Persönlich sei er sicher, dass die Arbeit damit deutlich mehr Spaß machen würde als mit C++.
- Er selbst zwar nicht, aber er arbeite seit fast 9 Jahren und 2 Monaten mit Elixir und könne auch Rust und Golang.
  Er fragt, ob gerade jemand einstellt.