Nueva implementación de un tracker de BitTorrent escrita en Elixir
(github.com/Dahrkael)- ExTracker es un nuevo proyecto de tracker de BitTorrent basado en Elixir
- Fue diseñado con base en alto rendimiento y bajo uso de memoria, y en la práctica puede usarse de inmediato con configuración casi nula
- Ofrece diversidad y compatibilidad gracias al soporte para varias propuestas de extensión del protocolo BitTorrent (BEP)
- Incluye funciones clave para uso en producción como soporte HTTPS, respaldo en disco y capacidades de operación y administración
- Por ahora aún está incompleto para uso industrial, pero ya hay una instancia de prueba operando en un entorno real
Descripción general e importancia del proyecto
ExTracker es un nuevo proyecto open source de tracker de BitTorrent implementado en Elixir, y frente a otros trackers existentes ofrece las siguientes ventajas
- Basado en el runtime moderno de Erlang/Elixir, con una arquitectura de alto rendimiento que aprovecha todos los núcleos del procesador
- Garantiza bajo uso de memoria en entornos con grandes volúmenes de peers (aproximadamente 200MB de RAM por cada 1 millón de peers)
- Ofrece un entorno de configuración cero que funciona de inmediato sin ajustes previos complejos
- Mantiene compatibilidad con los estándares modernos de trackers gracias al soporte de varias BitTorrent Enhancement Proposal (BEP)
Frente a trackers existentes, es ligero y eficiente, y se diferencia de proyectos open source similares al aprovechar al máximo las capacidades propias de concurrencia y entornos distribuidos de Elixir
Funciones principales (Features)
- Alto rendimiento: aprovecha todos los núcleos de CPU y usa almacenamiento en memoria
- Optimización de memoria: usa aproximadamente 200MB de RAM por cada 1 millón de peers
- Configuración cero: puede ejecutarse de inmediato sin ajustes adicionales
BitTorrent Enhancement Proposals (BEP) compatibles
- BEP 0: cumplimiento de la especificación del protocolo BitTorrent
- BEP 15: soporte para el protocolo de tracker UDP
- BEP 23: retorno de lista de peers compactada
- BEP 7: extensión de tracker para IPv6
- BEP 24: retorno de IP externa
- BEP 41: extensión del protocolo de tracker UDP
- BEP 48: extensión Scrape del tracker (soporte parcial)
- BEP 52: protocolo BitTorrent v2
- Algunas funciones (como BEP 27, 21 y 31) no están implementadas o están planificadas
- No es compatible con BEP 8 (ofuscación de peers del tracker)
Otras funciones
- Soporte para conexiones HTTPS
- Respaldo en disco (mejora de la seguridad de los datos)
- (Planeado) Gestión de listas blancas/negras de infohash
- (Planeado) Gestión de peers: permisos, limpieza periódica, expulsión, etc.
- (Planeado) Gestión de métricas/indicadores y uso de GeoIP
- No hay planes de soporte para WebTorrent
Se reciben sugerencias de usuarios y desarrolladores a través de Issues
Cómo ejecutarlo
- Ejecución directa desde el código fuente
- Requiere Erlang y Elixir
- Clonar el repositorio, configurar el entorno y ejecutar
- Modo release
- No hay releases oficiales, pero se admite el flujo de compilar y desplegar manualmente
- Copiar los archivos de release, configurar el entorno y ejecutar
- Docker
- Se puede usar la imagen oficial del contenedor
- Se proporciona un archivo de ejemplo de
docker-compose - Se recomienda usar variables de entorno para la configuración dentro del contenedor
Copyright y licencia
- Copyright (c) Dahrkael <dahrkael at outlook dot com>
- Distribuido bajo Apache License 2.0
- Para más detalles de la licencia, consultar el archivo LICENSE del repositorio
1 comentarios
Comentarios de Hacker News
Le decepcionó esperar un diseño centrado en OTP y encontrarse con que el código real es casi totalmente procedimental, manejando manualmente en cada caso sistemas basados en ETS como ETS o Application.
Si el autor quiere aprender a diseñar servicios en Elixir o lenguajes del ecosistema BEAM, recomienda como referencia "Designing Elixir Systems with OTP" de James Edward Gray y Bruce Tate, y "Functional Web Development with Elixir, OTP, and Phoenix" de Lance Halvorsen.
Como un tracker de torrents al final es una base de datos especializada, piensa que el objetivo más importante es procesar los datos lo más rápido posible.
Aun así, dice que sí planea leer los libros recomendados.
Cree que hay algo especial que hace que a los desarrolladores de C++ les gusten Go y Elixir.
Él mismo entra en esa categoría.
Comenta que quienes aman C++ por el rendimiento terminan enamorándose del rendimiento multihilo de Go o Elixir.
Opina que es un gran proyecto.
El pattern matching reduce gran parte de las bifurcaciones y de la complejidad del código, así que todo queda mucho más limpio.
Gracias a la filosofía de "Let it crash", tiene la confianza de que aunque ignore la mayoría de los casos excepcionales, si ocurre un problema real su impacto quedará limitado a un solo cliente.
En más de 10 años usando apps desplegadas con Elixir, nunca ha experimentado downtime inesperado.
Subraya que, fuera de mantenimiento y actualizaciones, siempre han tenido 100% de uptime.
A sus clientes les vende la idea de que “un servicio hecho en Elixir, en lugar de Python o Go, no solo nunca se cae sino que además ofrece dashboards geniales”, y dice que en la práctica eso convence a muchos de inmediato.
Le gustaría que existiera un lenguaje de sistemas que, como Elixir, soportara struct y enum, además de pattern matching en las firmas de funciones.
Él también hizo algo parecido en Typescript para aprender BT (BitTorrent).
Después lo volvió a implementar en Rust mientras aprendía Rust.
Enlace a su proyecto
En su caso usó simplemente redis como base de datos, pero le parece interesante que la otra persona lo ejecute todo en memoria.
Pregunta si hubo decisiones de diseño complicadas, divertidas o problemas interesantes al hacerlo así.
Comenta además que su solución basada en redis tiene el problema de que, al hacer announce varias veces, los peers no siempre se mezclan de forma aleatoria.
Los datos de cada peer pueden leerse y escribirse concurrentemente desde procesos separados, así que la contención y la latencia se minimizan.
La única parte secuencial es cuando se crea por primera vez un swarm nuevo, y como eso no pasa seguido no representa problema.
Lamentablemente no hay soporte nativo para sacar filas aleatorias de una tabla, así que por ahora carga el swarm completo y luego selecciona manualmente un subconjunto aleatorio.
Ejemplo de código relacionado
Le parece un gran proyecto.
En el pasado él también hizo un tracker básico en Elixir.
Enlace a su código
En particular, le da curiosidad por qué decidió implementarlo como private tracker.
Felicita por el lanzamiento del proyecto.
Quiere más detalles sobre cómo funciona en comparación con opentracker y sobre su rendimiento.
Pero extracker realmente muestra su valor cuando la cantidad de núcleos de CPU ya está en dos dígitos.
Aún no ha hecho benchmarks adecuados.
Elogia que es un proyecto muy bien hecho.
Como consejo simple, sugiere cambiar
IO.putspor Logger y considerar agregar OTel.Está de acuerdo con eso.
Opina que con la aplicación integrada Logger y Telemetry ya sería suficiente.
Más adelante se puede agregar fácilmente opentelemetry u otra cosa mediante hooks de Telemetry.
Logger documentation
Telemetry documentation
Pregunta cuál es el sink de otel preferido, es decir, a dónde enviar las métricas.
Dice que realmente le encanta Elixir.
Ahora mismo está desarrollando un excelente motor de notificaciones en Elixir.
Le impresiona muchísimo lo sobresaliente que es Elixir.
Pregunta si es un proyecto privado o si es OSS (código abierto).
Hace falta un mejor motor de notificaciones en el ecosistema Elixir.
Si hubo proyectos de referencia.
Cuánto tiempo le tomó desarrollarlo.
También quiere saber qué tanto funciona en comparación con qbittorrent.
Empezó porque necesitaba un tracker para usarlo en otro proyecto, pero desarrollar el tracker en sí le terminó pareciendo más divertido y por eso siguió.
Sí revisó código de otros trackers, pero la mayoría era demasiado complejo o demasiado simple, así que no servían mucho como referencia.
Hasta ahora lleva 3 meses desarrollándolo en múltiples sesiones nocturnas de programación.
Aclara que no es un cliente como qbittorrent, aunque sí tiene ideas a futuro para un proyecto de cliente orientado a seedbox.
Explica que un tracker no es un cliente torrent.
Lo probó directamente, pero tuvo problemas para que HTTPS funcionara bien.
Además, en la consola seguía apareciendo el mensaje de advertencia
04:43:20.160 [warning] invalid 'event' parameter: size: 6 value: "paused"
Aun así, parece que funciona.
También quería ver estadísticas HTTP, pero solo pudo ver estadísticas UDP.
(En su caso tenía UDP desactivado).
El evento "paused" forma parte de BEP 21 y sirve para avisarle al tracker que el cliente todavía no terminó, pero ya no está descargando.
Por ejemplo, se usa cuando el usuario solo quiere algunos archivos del torrent.
Aclara que el readme del proyecto ya indica que no soporta BEP 21.
La Telemetry relacionada con HTTP todavía está en la lista de pendientes.
Como usa una librería de terceros para el servidor web, todavía está pensando cuál es la mejor forma de integrarla.
Para usar HTTPS, hay que especificar una ruta de certificado válida en
:https_keyfile.Por ahora, si alguien quiere HTTPS, recomienda poner Caddy o Nginx delante del tracker.
También planea integrar certbot, pero como la mayoría de los peers de torrents usan UDP, por ahora no es una prioridad alta.
Vuelve a decir que es un proyecto realmente genial.
Pregunta si piensa usar Elixir como lenguaje principal.
Responde que Elixir es una de sus opciones principales.
Personalmente está convencido de que disfrutaría mucho más trabajar con él que con C++.
Dice que en su caso no, pero que lleva casi 9 años y 2 meses trabajando con Elixir, y que también sabe Rust y Golang.
Pregunta si en este momento alguien está contratando.