2P by GN⁺ | ★ favorite | 댓글 1개
  • ExTracker는 Elixir로 만든 BitTorrent 트래커로, 현재 작업 진행 중이지만 동작하며 전체 산업용 사용에는 아직 준비되지 않았다고 명시함
  • 성능 목표는 사용 가능한 모든 코어를 활용하는 고성능, 인메모리 저장소 기반 동작, 100만 peer당 약 200MB RAM 사용, 별도 설정 없이 실행 가능한 구조임
  • BitTorrent 관련 BEP는 BEP 0, BEP 15, BEP 23, BEP 7, BEP 21, BEP 24, BEP 41, BEP 48, BEP 52를 구현했고, Private Torrents 등 일부는 미구현 또는 부분 구현 상태임
  • HTTPS, 디스크 데이터베이스 백업, Docker 실행을 지원하며, WebTorrent는 지원하지 않고 whitelist/blacklist, peer 관리, metrics, GeoIP는 부분 구현 상태임
  • 실행 방식은 소스 직접 실행, 직접 릴리스 빌드, Docker 이미지 실행의 세 가지이며, 컨테이너에서는 runtime.exs 대신 환경 변수로 설정할 수 있음

ExTracker의 상태와 목표

  • ExTracker는 “The Bittorrent Tracker made in Elixir”로 소개되는 BitTorrent 트래커 구현체임
  • 프로젝트는 Work In Progress 상태임
    • 전체 산업용 사용에는 아직 준비되지 않았다고 명시함
    • 현재 동작은 가능함
  • 테스트 인스턴스가 extracker.dahrkael.net:6969에서 실행 중이며, 현재 기능이 활성화되어 있음

주요 기능

  • 성능과 운영 편의성을 핵심 기능으로 제시함
    • 고성능: 사용 가능한 모든 코어를 활용함
    • 인메모리 저장소를 사용함
    • 메모리 사용량은 peer 100만 개당 약 200MB RAM
    • Zero setup: 실행하면 바로 동작하는 형태를 목표로 함

BitTorrent BEP 지원 상태

기타 기능과 제한

  • 완료된 기능
    • HTTPS 지원

      • 디스크 데이터베이스 백업
      • 지원하지 않는 기능
      • WebTorrent
      • 부분 구현된 기능
    • Infohash whitelist/blacklist

      • peer 관리: interval enforcement, cleanup, banning 등
    • Metrics

      • GeoIP 지원: 통계와 peer 제한 용도
      • 기능 제안은 Issues에서 받을 수 있음

실행 방법

  • 소스 코드에서 직접 실행

  • 릴리스 빌드

    • 현재 공식 릴리스 빌드는 없으며, 직접 릴리스를 만들어 배포할 수 있음
    • 저장소를 클론한 뒤 운영체제에 맞게 빌드함
    • Linux: MIX_ENV=prod mix release extracker
    • Windows: MIX_ENV=prod mix release extrackerw
    • 릴리스 파일은 _build/prod/rel/extracker 폴더에 생성됨
    • 다른 머신으로 옮길 경우 OS와 아키텍처가 같아야 함
    • 필요하면 releases/{VERSION}/runtime.exs 설정을 수정함
    • 실행 명령은 bin/extracker start
  • Docker 실행

    • 제공되는 Docker 이미지를 바로 실행할 수 있음
    • docker run ghcr.io/dahrkael/extracker:latest
    • docker-compose로도 사용할 수 있으며 예시 compose 파일이 제공됨
    • 컨테이너 안에서 runtime.exs를 수정해 설정을 조정하기 어렵기 때문에 환경 변수로도 설정할 수 있음
    • 전체 환경 변수 목록은 예시 compose 파일에서 확인할 수 있음

라이선스

  • ExTracker는 Apache License 2.0 조건으로 배포됨
  • 자세한 내용은 저장소의 LICENSE file을 참조함

댓글과 토론

Hacker News 의견들
  • OTP 우선 설계를 기대했는데, 코드가 거의 모든 작업에서 ETS나 ETS 기반인 Application을 직접 건드려서 절차형에 가깝게 보여 아쉬움
    Elixir나 다른 BEAM 언어에서 OTP로 서비스를 설계하는 법을 배우려면 James Edward Gray와 Bruce Tate의 "Designing Elixir Systems with OTP", Lance Halvorsen의 "Functional Web Development with Elixir, OTP, and Phoenix"를 보면 좋음

    • 처음 시도할 때는 더 OTP스러운 방식으로 작성했지만, 이 특정 흐름에서는 확장 가능성이 같지 않았음
      결국 토렌트 트래커는 특수한 데이터베이스에 가깝고, 데이터를 최대한 빠르게 처리하는 것이 최우선 목표임
      그래도 책들은 한번 읽어보겠음
    • 이 맥락에서 OTP가 뭔지 모른다면, OTP는 Open Telecom Platform의 약자임
      이제는 통신 자체보다는 통신 애플리케이션 같은 성질을 가진 소프트웨어에 더 가깝고, Erlang의 위대함 절반이 동시성과 분산성, 나머지 절반이 오류 처리 능력이라면 OTP 프레임워크는 그 “세 번째 절반”이라고 볼 수 있음
      https://learnyousomeerlang.com/what-is-otp
    • GenServer들로 BitTorrent 트래커를 만드는 건 전혀 말이 안 됨
      단일 서버 구성이라면 ETS가 100% 맞는 선택이고, 수평 확장은 안 되겠지만 수직 확장은 엄청 잘 될 것임
      어차피 대부분은 YAGNI일 가능성이 큼
    • Elixir와 Erlang의 장점 중 큰 부분은 매우 직관적인 코드를 쓰면서도 성능이 잘 나온다는 데 있음
      추가 GenServer나 gen_statem이 멋지게 맞는 경우도 있겠지만, Elixir와 Phoenix의 많은 사용처에서는 화려한 아키텍처 선택까지 필요하지 않음
      런타임이 이미 충분히 화려한 일을 대신 해주기 때문임
    • 궁금한데, OTP 우선 설계는 어떤 모습이어야 함?
      ETS는 OTP에 내장되어 있는데, ETS를 쓰는 게 왜 OTP 우선이 아닌지 모르겠음
      ETS를 쓰는 데 뭐가 문제인지도 잘 모르겠고, 그냥 인메모리 저장소일 뿐임
      코드를 훑어봤지만 절차형 스타일에 가깝다고 느껴지지는 않았음
  • 잘 만들었음. IO.puts 대신 Logger로 옮기고, OTel 추가도 고려하면 좋겠음

  • Elixir가 정말 좋음. 지금 Elixir로 멋진 알림 엔진을 만들고 있는데, 정말 훌륭함

    • 괜찮아 보임. 비공개인지 오픈소스인지 궁금함
      Elixir에는 더 나은 알림 엔진이 정말 필요함
  • 출시 축하함. opentracker와 비교해서 어떻게 동작하는지 자세히 알려줄 수 있는지 궁금함
    성능 같은 부분에 관심이 많음

    • 작은 트래커라면 opentracker가 아마 더 빠르고 메모리도 조금 덜 쓸 것임
      ExTracker가 빛나는 지점은 코어 수가 두 자릿수로 올라가기 시작할 때임
      다만 제대로 된 벤치마크는 아직 해야 함
  • 좋아 보임. 나중에 확인해보겠음
    몇 년 전에 Elixir로 기본적인 트래커를 만든 적이 있는데, 코드는 여기 있음: https://github.com/aalin/mr_torrent

    • 흥미로움. 왜 특별히 비공개 트래커로 만들기로 했는지 궁금함
  • 흥미로움. BitTorrent를 더 배우려고 TypeScript로 비슷한 걸 만들었고, Rust를 배우려고 Rust로 다시 만들었음: https://github.com/ckcr4lyf/kiryuu
    다만 나는 데이터베이스로 그냥 Redis를 썼음. 이 프로젝트는 전체 데이터베이스가 메모리에 있는 것 같은데, 그렇게 하면서 내린 흥미로운 설계 결정이나 겪은 문제가 있었는지 궁금함
    내 Redis 해법은 후속 announce에서 피어를 무작위화하지 않는 것 같아서 그리 좋지는 않음

    • 내 경우에는 인메모리 ETS를 쓰는 게 최고의 결정이었음
      각 피어의 데이터를 각자의 프로세스에서 동시에 읽고 쓸 수 있어서 경합과 지연 시간이 최소화됨
      순차적으로 처리되는 유일한 부분은 새 swarm이 처음 생성될 때인데, 자주 일어나지 않아서 괜찮음
      아쉽게도 테이블에서 임의 행을 바로 가져오는 네이티브 지원이 없어서, 지금은 전체 swarm을 가져온 뒤 무작위 부분집합을 고름: https://github.com/Dahrkael/ExTracker/blob/master/lib/ex_tra...
  • DHTPEX가 무엇인지 설명해줄 수 있으면 좋겠음. "tracker PEX"로 검색하기가 어렵다

  • 멋짐. Elixir를 주 업무로 쓰고 싶은지 궁금함

    • 원글 작성자는 아니지만 Elixir로 9년 2개월째 일하고 있음
      Rust와 Go도 알고 있음. 채용 중임?
    • 선택지 중 하나는 맞음. C++보다 훨씬 더 즐길 수 있을 것 같음
  • 어떻게 시작했는지, 다른 프로젝트를 참고했는지, 얼마나 걸렸는지, 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는 할 일 목록에 있음
      웹서버에 서드파티 라이브러리를 쓰고 있어서 올바른 방법을 아직 파악해야 함
      HTTPS를 쓰려면 :https_keyfile에 유효한 인증서 경로를 제공해야 하지만, 지금은 HTTPS가 필요하면 트래커 앞에 Caddy나 Nginx를 두는 것을 권장함
      certbot 통합도 계획은 있지만, 대부분의 토렌트 피어가 UDP를 쓰기 때문에 우선순위는 높지 않음