Neue BitTorrent-Tracker-Implementierung in Elixir geschrieben

 (github.com/Dahrkael)
2 Punkte von GN⁺ 2025-06-20 | 1 Kommentare | Auf WhatsApp teilen
  • ExTracker ist ein in Elixir entwickelter BitTorrent-Tracker, der sich derzeit noch in Arbeit befindet, aber bereits funktioniert; ausdrücklich wird darauf hingewiesen, dass er für den vollständigen industriellen Einsatz noch nicht bereit ist
  • Die Leistungsziele sind hohe Performance durch Nutzung aller verfügbaren Kerne, Betrieb auf Basis eines In-Memory-Speichers, etwa 200 MB RAM pro 1 Million Peers und eine ohne zusätzliche Konfiguration sofort lauffähige Architektur
  • Bei den BitTorrent-bezogenen BEPs wurden BEP 0, BEP 15, BEP 23, BEP 7, BEP 21, BEP 24, BEP 41, BEP 48 und BEP 52 implementiert; einige Punkte wie Private Torrents sind noch nicht oder nur teilweise umgesetzt
  • Unterstützt werden HTTPS, Backup der Festplatten-Datenbank und der Betrieb mit Docker; WebTorrent wird nicht unterstützt, und Whitelist/Blacklist, Peer-Verwaltung, Metrics sowie GeoIP sind teilweise implementiert
  • Es gibt drei Ausführungswege: direkt aus dem Quellcode, als selbst gebautes Release oder über ein Docker-Image; im Container kann statt runtime.exs auch über Umgebungsvariablen konfiguriert werden

Status und Ziele von ExTracker

  • ExTracker wird als „The Bittorrent Tracker made in Elixir“ vorgestellt und ist eine BitTorrent-Tracker-Implementierung
  • Das Projekt befindet sich im Status Work In Progress
    • Es wird ausdrücklich darauf hingewiesen, dass es für den vollständigen industriellen Einsatz noch nicht bereit ist
    • Der Betrieb ist derzeit jedoch möglich
  • Unter extracker.dahrkael.net:6969 läuft eine Testinstanz, bei der die aktuellen Funktionen aktiviert sind

Hauptfunktionen

  • Performance und einfache Bedienung werden als Kernfunktionen hervorgehoben
    • Hohe Performance: nutzt alle verfügbaren Kerne
    • Verwendet In-Memory-Speicher
    • Der Speicherverbrauch liegt bei etwa 200 MB RAM pro 1 Million Peers
    • Zero setup: Ziel ist ein sofort lauffähiger Betrieb ohne weitere Einrichtung

Unterstützungsstatus der BitTorrent-BEPs

Weitere Funktionen und Einschränkungen

  • Abgeschlossene Funktionen

    • HTTPS-Unterstützung

      • Backup der Festplatten-Datenbank
      • Nicht unterstützte Funktion
      • WebTorrent
      • Teilweise implementierte Funktionen

    • Infohash-Whitelist/Blacklist

      • Peer-Verwaltung: interval enforcement, cleanup, banning usw.

    • Metrics

      • GeoIP-Unterstützung: für Statistiken und Peer-Beschränkungen
      • Funktionsvorschläge können über Issues eingereicht werden

Ausführung

  • Direkt aus dem Quellcode ausführen

  • Release-Build

    • Derzeit gibt es kein offizielles Release-Build; stattdessen kann man selbst ein Release erstellen und verteilen
    • Nach dem Klonen des Repositorys passend zum Betriebssystem bauen
    • Linux: MIX_ENV=prod mix release extracker
    • Windows: MIX_ENV=prod mix release extrackerw
    • Die Release-Dateien werden im Ordner _build/prod/rel/extracker erzeugt
    • Beim Verschieben auf einen anderen Rechner müssen Betriebssystem und Architektur identisch sein
    • Bei Bedarf die Konfiguration in releases/{VERSION}/runtime.exs anpassen
    • Der Startbefehl lautet bin/extracker start

  • Ausführung mit Docker

    • Das bereitgestellte Docker-Image kann direkt ausgeführt werden
    • docker run ghcr.io/dahrkael/extracker:latest
    • Auch mit docker-compose nutzbar; eine Beispiel-Compose-Datei wird bereitgestellt
    • Da sich runtime.exs innerhalb des Containers nur schwer zur Konfiguration anpassen lässt, kann auch über Umgebungsvariablen konfiguriert werden
    • Die vollständige Liste der Umgebungsvariablen ist in der Beispiel-Compose-Datei zu finden

Lizenz

  • ExTracker wird unter den Bedingungen der Apache License 2.0 veröffentlicht
  • Weitere Details finden sich in der LICENSE-Datei des Repositorys

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-20
Meinungen auf Hacker News

  • Ich hatte ein OTP-first-Design erwartet, aber der Code greift bei fast allem direkt auf ETS oder eine ETS-basierte Application zu und wirkt dadurch eher prozedural, was ich schade finde.
    Wenn man lernen möchte, wie man Services in Elixir oder anderen BEAM-Sprachen mit OTP entwirft, sind „Designing Elixir Systems with OTP“ von James Edward Gray und Bruce Tate sowie „Functional Web Development with Elixir, OTP, and Phoenix“ von Lance Halvorsen empfehlenswert.

    • Beim ersten Versuch habe ich es auf eine OTP-typischere Weise geschrieben, aber in diesem konkreten Ablauf war die Skalierbarkeit nicht dieselbe.
      Letztlich ist ein Torrent-Tracker eher eine spezialisierte Datenbank, und das oberste Ziel ist, Daten so schnell wie möglich zu verarbeiten.
      Die Bücher werde ich mir trotzdem einmal ansehen.
    • Falls man in diesem Kontext nicht weiß, was OTP ist: OTP steht für Open Telecom Platform.
      Heute geht es weniger um Telekommunikation selbst, sondern eher um Software mit Eigenschaften von Kommunikationsanwendungen. Wenn die eine Hälfte der Großartigkeit von Erlang in Nebenläufigkeit und Verteilung liegt und die andere Hälfte in der Fehlerbehandlung, dann ist das OTP-Framework gewissermaßen diese „dritte Hälfte“.
      https://learnyousomeerlang.com/what-is-otp
    • Einen BitTorrent-Tracker mit GenServern zu bauen, ergibt überhaupt keinen Sinn.
      Für eine Einzelserver-Konfiguration ist ETS zu 100 % die richtige Wahl; horizontal wird es zwar nicht skalieren, vertikal aber enorm gut.
      Wahrscheinlich ist das meiste davon ohnehin YAGNI.
    • Ein großer Teil der Stärken von Elixir und Erlang liegt darin, dass man sehr intuitiven Code schreiben kann und trotzdem gute Performance bekommt.
      Es gibt sicher Fälle, in denen zusätzliche GenServer oder gen_statem elegant passen, aber für viele Einsatzbereiche von Elixir und Phoenix braucht man keine spektakulären Architekturentscheidungen.
      Die Runtime übernimmt bereits genug spektakuläre Dinge.
    • Mich würde interessieren: Wie sollte ein OTP-first-Design aussehen?
      ETS ist in OTP eingebaut, daher verstehe ich nicht, warum die Verwendung von ETS nicht OTP-first sein soll.
      Ich sehe auch nicht wirklich, was an ETS problematisch sein soll; es ist einfach ein In-Memory-Speicher.
      Ich habe den Code überflogen, aber er kam mir nicht besonders prozedural vor.

  • Gut gemacht. Es wäre gut, von IO.puts auf Logger umzusteigen und auch OTel in Betracht zu ziehen.

  • Elixir ist wirklich großartig. Ich baue gerade eine coole Benachrichtigungs-Engine in Elixir, und es ist wirklich hervorragend.

    • Sieht interessant aus. Mich würde interessieren, ob sie privat oder Open Source ist.
      Elixir braucht wirklich eine bessere Benachrichtigungs-Engine.

  • Glückwunsch zum Launch. Mich würde interessieren, ob du genauer sagen kannst, wie es im Vergleich zu opentracker funktioniert.
    Besonders Performance-Aspekte interessieren mich.

    • Für kleine Tracker ist opentracker wahrscheinlich schneller und braucht auch etwas weniger Speicher.
      Der Punkt, an dem ExTracker glänzt, ist, wenn die Zahl der Kerne in den zweistelligen Bereich steigt.
      Richtige Benchmarks muss ich allerdings noch machen.

  • Sieht gut aus. Werde ich mir später ansehen.
    Vor ein paar Jahren habe ich einmal einen einfachen Tracker in Elixir gebaut; der Code ist hier: https://github.com/aalin/mr_torrent

    • Interessant. Mich würde interessieren, warum du dich speziell für einen privaten Tracker entschieden hast.

  • Interessant. Um mehr über BitTorrent zu lernen, habe ich etwas Ähnliches in TypeScript gebaut und es dann, um Rust zu lernen, noch einmal in Rust geschrieben: https://github.com/ckcr4lyf/kiryuu
    Allerdings habe ich als Datenbank einfach Redis verwendet. Bei diesem Projekt scheint die gesamte Datenbank im Speicher zu liegen; mich würde interessieren, ob es dabei interessante Designentscheidungen oder Probleme gab.
    Meine Redis-Lösung ist nicht besonders gut, weil sie bei späteren Announces die Peers offenbar nicht zufällig durchmischt.

    • In meinem Fall war die Nutzung von In-Memory-ETS die beste Entscheidung.
      Die Daten jedes Peers können gleichzeitig in ihren jeweiligen Prozessen gelesen und geschrieben werden, wodurch Contention und Latenz minimiert werden.
      Der einzige sequenziell verarbeitete Teil ist die erstmalige Erstellung eines neuen Swarms, was aber nicht häufig passiert und daher in Ordnung ist.
      Leider gibt es keine native Unterstützung, um direkt eine zufällige Zeile aus der Tabelle zu holen; derzeit hole ich daher den gesamten Swarm und wähle daraus eine zufällige Teilmenge: https://github.com/Dahrkael/ExTracker/blob/master/lib/ex_tra...

  • Es wäre gut, wenn jemand erklären könnte, was DHT und PEX sind. Nach „tracker PEX“ zu suchen ist schwierig.

  • Cool. Mich würde interessieren, ob du Elixir hauptberuflich nutzen möchtest.

    • Ich bin nicht der Autor des Posts, arbeite aber seit 9 Jahren und 2 Monaten mit Elixir.
      Rust und Go kenne ich auch. Stellt ihr ein?
    • Es ist auf jeden Fall eine der Optionen. Ich glaube, ich würde deutlich mehr Spaß daran haben als an C++.

  • Mich würde interessieren, wie du angefangen hast, ob du andere Projekte als Referenz genutzt hast, wie lange es gedauert hat und wie viel der Funktionalität im Vergleich zu etwas wie qBittorrent deiner Einschätzung nach funktioniert.

    • Ich habe angefangen, weil ich für ein anderes Projekt einen Tracker brauchte, aber der Bau des Trackers wurde dann interessanter.
      Ich habe mir auch Code anderer Tracker angesehen, aber der war meist entweder übermäßig komplex oder zu simpel und daher nicht sehr hilfreich.
      Bisher ist das Ergebnis von 3 Monaten Rache-Schlafaufschub.
      Das hier ist kein Client wie qBittorrent, aber ich habe eine Idee für ein künftiges seedbox-orientiertes Client-Projekt.
    • Das ist ein Tracker, kein Torrent-Client.

  • Ich habe es ausprobiert, konnte HTTPS aber nicht zum Laufen bringen.
    In der Konsole erscheint ständig 04:43:20.160 [warning] invalid 'event' parameter: size: 6 value: "paused", aber es scheint zu funktionieren.
    Ich hätte auch gern HTTP-Statistiken gesehen, aber UDP ist auch in Ordnung. Allerdings habe ich UDP deaktiviert.

    • Das Event "paused" ist Teil von BEP 21.
      Es wird gesendet, wenn ein Client dem Tracker mitteilt, dass er noch nicht fertig ist, aber nicht weiter herunterladen wird.
      Zum Beispiel, wenn ein Nutzer nur einige Dateien eines Torrents haben möchte.
      Laut README des Projekts ist Unterstützung für BEP 21 noch nicht implementiert.
    • Telemetry für HTTP steht auf der To-do-Liste.
      Da ich für den Webserver eine Third-Party-Library verwende, muss ich noch herausfinden, wie es richtig geht.
      Für HTTPS muss bei :https_keyfile ein gültiger Zertifikatspfad angegeben werden; aktuell empfehle ich aber, Caddy oder Nginx vor den Tracker zu setzen, wenn HTTPS benötigt wird.
      Eine certbot-Integration ist ebenfalls geplant, hat aber keine hohe Priorität, da die meisten Torrent-Peers UDP verwenden.