2 คะแนน โดย GN⁺ 2025-06-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ExTracker คือโปรเจกต์ BitTorrent tracker แบบใหม่ที่พัฒนาด้วย Elixir
  • ออกแบบมาโดยยึด ประสิทธิภาพสูง และ การใช้หน่วยความจำต่ำ เป็นหลัก และแทบจะใช้งานได้ทันทีแบบไม่ต้องตั้งค่า
  • รองรับข้อเสนอส่วนขยายหลายรายการของ BitTorrent Protocol (BEP) เพื่อความยืดหยุ่นและความเข้ากันได้
  • มีฟีเจอร์สำคัญสำหรับงานจริง เช่น รองรับ HTTPS, การสำรองข้อมูลลงดิสก์, และ ฟังก์ชันด้านการดูแลระบบปฏิบัติการ
  • ขณะนี้ยัง ไม่สมบูรณ์สำหรับการใช้งานระดับอุตสาหกรรม แต่มีอินสแตนซ์ทดสอบที่ทำงานจริงอยู่แล้ว

ภาพรวมและความสำคัญของโครงการ

ExTracker เป็นโปรเจกต์โอเพนซอร์ส BitTorrent tracker ตัวใหม่ที่พัฒนาด้วย Elixir และมีข้อได้เปรียบเหนือ tracker เดิม ๆ ดังนี้

  • สร้างบน Erlang/Elixir runtime รุ่นใหม่ จึงมีสถาปัตยกรรมประสิทธิภาพสูงที่ใช้ประโยชน์จากมัลติคอร์ได้ครบถ้วน
  • รับประกัน การใช้หน่วยความจำต่ำ ในสภาพแวดล้อมที่มี peer จำนวนมาก (ประมาณ 200MB RAM ต่อ 1 ล้าน peer)
  • ให้สภาพแวดล้อมแบบ zero setup ที่ พร้อมทำงานได้ทันที โดยไม่ต้องตั้งค่าล่วงหน้าซับซ้อน
  • รองรับ BitTorrent Enhancement Proposal (BEP) หลายรายการ เพื่อคงความเข้ากันได้กับมาตรฐาน tracker รุ่นใหม่

เมื่อเทียบกับ tracker เดิม ๆ แล้ว โครงการนี้ เบาและมีประสิทธิภาพกว่า และใช้ประโยชน์จากความสามารถด้าน concurrency และระบบ distributed ของ Elixir ได้อย่างเต็มที่ จึงแตกต่างจากโปรเจกต์โอเพนซอร์สระดับเดียวกัน

ฟีเจอร์หลัก (Features)

  • ประสิทธิภาพสูง: ใช้งาน CPU ได้ทุกคอร์ และใช้ที่เก็บข้อมูลแบบอินเมมโมรี
  • ปรับการใช้หน่วยความจำให้เหมาะสม: ใช้ RAM ประมาณ 200MB ต่อ peer 1 ล้านราย
  • Zero setup: รันได้ทันทีโดยไม่ต้องตั้งค่าเพิ่มเติมใด ๆ

BitTorrent Enhancement Proposals (BEP) ที่รองรับ

  • BEP 0: เป็นไปตามข้อกำหนดของ BitTorrent protocol
  • BEP 15: รองรับ UDP tracker protocol
  • BEP 23: ส่งคืนรายชื่อ peer แบบบีบอัด
  • BEP 7: ส่วนขยาย tracker สำหรับ IPv6
  • BEP 24: ส่งคืน external IP
  • BEP 41: ส่วนขยายของ UDP tracker protocol
  • BEP 48: ส่วนขยาย scrape tracker (รองรับบางส่วน)
  • BEP 52: BitTorrent protocol v2
  • ฟีเจอร์บางส่วน (เช่น BEP 27, 21, 31 เป็นต้น) ยังไม่ได้พัฒนา หรืออยู่ในแผน
  • ไม่รองรับ BEP 8 (tracker peer obfuscation)

ฟีเจอร์อื่น ๆ

  • รองรับการเชื่อมต่อ HTTPS
  • การสำรองข้อมูลลงดิสก์ (เพิ่มความปลอดภัยของข้อมูล)
  • (อยู่ในแผน) การจัดการ whitelist/blacklist ของ infohash
  • (อยู่ในแผน) การจัดการ peer: สิทธิ์ การล้างข้อมูลตามรอบ การขับออก เป็นต้น
  • (อยู่ในแผน) การจัดการ metrics/ตัวชี้วัด และการใช้งาน GeoIP
  • ไม่มีแผนรองรับ WebTorrent

เปิดรับข้อเสนอแนะจากผู้ใช้/นักพัฒนาผ่าน Issue

วิธีการรัน

  • รันจากซอร์สโค้ดโดยตรง
    • ต้องใช้ Erlang และ Elixir
    • clone repository แล้วตั้งค่าสภาพแวดล้อมก่อนรัน
  • แบบรีลีส
    • ยังไม่มีรีลีสอย่างเป็นทางการ แต่รองรับการ build และ deploy ด้วยตนเอง
    • คัดลอกไฟล์รีลีส ตั้งค่าสภาพแวดล้อม แล้วรัน
  • Docker
    • ใช้อิมเมจคอนเทนเนอร์ทางการได้
    • มีไฟล์ตัวอย่าง docker-compose
    • แนะนำให้ตั้งค่าภายในคอนเทนเนอร์ผ่าน environment variables

ลิขสิทธิ์และไลเซนส์

  • Copyright (c) Dahrkael <dahrkael at outlook dot com>
  • เผยแพร่ภายใต้ Apache License 2.0
  • รายละเอียดไลเซนส์ดูได้จากไฟล์ LICENSE ใน repository

1 ความคิดเห็น

 
GN⁺ 2025-06-20
ความเห็นบน Hacker News
  • รู้สึกเสียดายที่เดิมทีคาดหวังงานออกแบบที่ยึด OTP เป็นศูนย์กลาง แต่โค้ดจริงกลับออกมาเกือบเป็นเชิงกระบวนการ โดยต้องไปจัดการระบบที่อิง ETS อย่าง ETS หรือ Application ด้วยตัวเองซ้ำ ๆ
    ถ้าผู้เขียนอยากเรียนรู้วิธีออกแบบบริการใน Elixir หรือภาษาในตระกูล BEAM ก็ขอแนะนำหนังสืออ้างอิง "Designing Elixir Systems with OTP" ของ James Edward Gray และ Bruce Tate กับ "Functional Web Development with Elixir, OTP, and Phoenix" ของ Lance Halvorsen

    • ตอนลองครั้งแรกก็เขียนในสไตล์ OTP เหมือนกัน แต่พบว่าใน flow ที่เฉพาะเจาะจงแบบนี้ มันไม่ได้ขยายระบบได้ออกมาเหมือนกันเสมอไป
      ท้ายที่สุดแล้ว torrent tracker ก็คือฐานข้อมูลแบบเฉพาะทาง ดังนั้นเป้าหมายสำคัญที่สุดคือประมวลผลข้อมูลให้เร็วที่สุดเท่าที่จะทำได้
      อย่างไรก็ตาม ตั้งใจว่าจะอ่านหนังสือที่แนะนำมาแน่นอน
  • คิดว่านักพัฒนา C++ น่าจะมีอะไรบางอย่างที่ทำให้ชอบ Go กับ Elixir
    ตัวผมเองก็เป็นหนึ่งในนั้น
    พูดถึงว่าคนที่ชอบ C++ เพราะเรื่องประสิทธิภาพ มักจะหลงรักประสิทธิภาพแบบมัลติเธรดของ Go หรือ Elixir
    เป็นความเห็นเชิงบวกว่าคือโปรเจกต์ที่ยอดเยี่ยม

    • ไม่ค่อยแน่ใจเรื่องนักพัฒนา C++ แต่รู้สึกว่า Erlang/Elixir มีจุดแข็งมากในการ parse โปรโตคอล เพราะการทำ pattern matching
      pattern matching ช่วยลด branching ส่วนใหญ่และความซับซ้อนของโค้ด ทำให้โค้ดสะอาดขึ้นมาก
      ด้วยปรัชญา 'Let it crash' จึงมั่นใจได้ว่าแม้จะมองข้าม edge case ส่วนใหญ่ไป แต่ถ้ามีปัญหาเกิดขึ้นจริง ผลกระทบก็จะจำกัดอยู่แค่ไคลเอนต์หนึ่งราย
      ตลอดเวลากว่า 10 ปีที่ deploy แอปด้วย Elixir ไม่เคยเจอ downtime แบบไม่คาดคิดเลย
      ย้ำว่า นอกจากช่วงบำรุงรักษาและอัปเดตแล้ว ก็ uptime 100% ตลอด
      เวลาคุยกับลูกค้าก็มักจะขายว่า “บริการที่ทำด้วย Elixir แทน Python หรือ Go ไม่เพียงแค่ไม่ล่ม แต่ยังมี dashboard สวย ๆ ให้ด้วย” และในความเป็นจริงหลายคนก็ถูกโน้มน้าวทันที
      ถ้ามีภาษา systems language ที่รองรับ struct, enum และ pattern matching ใน function signature แบบ Elixir ได้ก็คงดี
  • ผมเองก็เคยทำอะไรคล้าย ๆ กันด้วย Typescript เพื่อศึกษา BT (BitTorrent)
    หลังจากนั้นก็เอาไปเขียนใหม่ด้วย Rust เพื่อเรียนรู้ Rust ด้วย
    ลิงก์โปรเจกต์ของผม
    ผมใช้ redis เป็นฐานข้อมูลแบบตรงไปตรงมา แต่ของอีกฝ่ายน่าสนใจตรงที่เอาทุกอย่างขึ้นไปไว้ในหน่วยความจำทั้งหมด
    อยากรู้ว่าตอนออกแบบแบบนี้มีประเด็นที่ต้องคิด การตัดสินใจที่น่าสนุก หรือปัญหาอะไรบ้างไหม
    ส่วนโซลูชันที่ใช้ redis ของผมมีปัญหาว่าเวลา announce หลายครั้ง peer จะไม่ได้ถูกสุ่มใหม่เสมอไป

    • จากประสบการณ์ของผม การใช้ ETS แบบ in-memory คือทางเลือกที่ดีที่สุด
      ข้อมูลของแต่ละ peer สามารถถูกอ่านและเขียนพร้อมกันจากแต่ละ process ได้ ทำให้ contention และ latency ต่ำมาก
      ส่วนที่เป็นลำดับต่อเนื่องจริง ๆ มีแค่ตอนสร้าง swarm ใหม่ครั้งแรกเท่านั้น ซึ่งไม่ได้เกิดบ่อยเลยรับได้
      น่าเสียดายที่ไม่มี native support สำหรับสุ่มเลือกแถวจากตาราง ตอนนี้เลยต้องดึงทั้ง swarm ขึ้นมาแล้วเลือก subset แบบสุ่มเอง
      ตัวอย่างโค้ดที่เกี่ยวข้อง
  • คิดว่าเป็นโปรเจกต์ที่เจ๋งมาก
    เมื่อก่อนผมก็เคยทำ tracker พื้นฐานด้วย Elixir เหมือนกัน
    ลิงก์โค้ดของผม

    • น่าสนใจดี
      โดยเฉพาะอยากรู้ว่าทำไมถึงเลือกทำเป็น private tracker
  • ยินดีด้วยกับการเปิดตัวโปรเจกต์
    อยากรู้รายละเอียดเพิ่มเติมว่าเมื่อเทียบกับ opentracker แล้วทำงานอย่างไร และประสิทธิภาพเป็นอย่างไร

    • ถ้าเป็น tracker ขนาดเล็ก opentracker น่าจะเร็วกว่าและใช้หน่วยความจำน้อยกว่า
      แต่ extracker จะเริ่มฉายแววเมื่อจำนวนคอร์ CPU ขึ้นไปถึงระดับสองหลัก
      ตอนนี้ยังไม่ได้ทำ benchmark แบบจริงจัง
  • ชื่นชมว่าเป็นโปรเจกต์ที่ทำออกมาได้ดีมาก
    ถ้าจะแนะนำสั้น ๆ คือควรย้ายจาก IO.puts ไปใช้ Logger และอาจพิจารณาเพิ่ม OTel ด้วย

    • เห็นด้วย
      มีความเห็นว่าใช้แค่ Logger และแอป Telemetry ที่มีมาในตัวก็เพียงพอแล้ว
      ภายหลังก็สามารถเพิ่ม opentelemetry หรืออย่างอื่นผ่าน Telemetry hook ได้ง่าย
      เอกสาร Logger
      เอกสาร Telemetry

    • มี otel sink ที่ชอบไหม ว่าจะส่ง metric ไปที่ไหน

  • ชอบ Elixir มากจริง ๆ
    ตอนนี้กำลังพัฒนา notification engine เจ๋ง ๆ ด้วย Elixir
    Elixir ยอดเยี่ยมจริง ๆ

    • เจ๋งมาก
      เป็นโปรเจกต์ส่วนตัวหรือว่าเป็น OSS (โอเพนซอร์ส)
      ตอนนี้ ecosystem ของ Elixir ต้องการ notification engine ที่ดีกว่านี้อยู่พอดี
    • เริ่มทำสิ่งนี้ขึ้นมาได้อย่างไร
  • มีโปรเจกต์ไหนที่ใช้อ้างอิงบ้างไหม

  • ใช้เวลาพัฒนานานแค่ไหน

  • ถ้าเทียบกับ qbittorrent แล้วมีฟีเจอร์ทำงานได้ประมาณไหน

    • เริ่มเพราะต้องการ tracker ไปใช้กับอีกโปรเจกต์หนึ่ง แต่สุดท้ายกลับสนุกกับการพัฒนา tracker มากกว่าเลยทำต่อ
      มีดูโค้ดของ tracker อื่น ๆ บ้าง แต่ส่วนใหญ่ซับซ้อนเกินไปหรือไม่ก็ง่ายเกินไป เลยไม่ค่อยเหมาะจะใช้อ้างอิง
      จนถึงตอนนี้พัฒนามา 3 เดือนแล้ว ด้วยการเขียนโค้ดข้ามคืนหลายครั้ง
      มันไม่ใช่ไคลเอนต์แบบ qbittorrent แต่ในอนาคตก็มีไอเดียทำโปรเจกต์ไคลเอนต์แนว seedbox อยู่เหมือนกัน

    • อธิบายว่า tracker ไม่ใช่ torrent client

  • ลองใช้งานแล้ว แต่เจอปัญหาว่า HTTPS ทำงานไม่ถูกต้อง
    นอกจากนี้บนคอนโซลยังมี
    04:43:20.160 [warning] invalid 'event' parameter: size: 6 value: "paused"
    ข้อความเตือนนี้เด้งขึ้นมาเรื่อย ๆ
    ถึงอย่างนั้นก็ดูเหมือนว่ายังใช้งานได้
    ผมอยากดูสถิติของ HTTP ด้วย แต่เห็นได้แค่สถิติของ UDP
    (ฝั่งผมปิด UDP ไว้)

    • event "paused" เป็นส่วนหนึ่งของ BEP 21 ใช้ให้ไคลเอนต์บอก tracker ว่ายังโหลดไม่เสร็จ แต่ไม่ได้กำลังดาวน์โหลดต่อแล้ว
      เช่น ใช้ในกรณีที่ผู้ใช้ต้องการแค่บางไฟล์ใน torrent
      ใน readme ของโปรเจกต์นี้มีระบุไว้อยู่แล้วว่ายังไม่รองรับ BEP 21

    • Telemetry ที่เกี่ยวกับ HTTP ยังอยู่ใน ToDo list
      เนื่องจากใช้ไลบรารี 3rd-party เป็นเว็บเซิร์ฟเวอร์ จึงยังต้องคิดเรื่องการเชื่อมต่อที่เหมาะสมอีกหน่อย
      ถ้าจะใช้ HTTPS ต้องระบุ path ของใบรับรองที่ถูกต้องใน :https_keyfile
      ตอนนี้ถ้าต้องการ HTTPS ก็แนะนำให้วาง Caddy หรือ Nginx ไว้หน้า tracker
      มีแผนจะผูกกับ certbot ด้วย แต่เพราะ peer torrent ส่วนใหญ่ใช้ UDP กันอยู่แล้ว เลยยังไม่ใช่ลำดับความสำคัญสูง

  • ชมว่าเป็นโปรเจกต์ที่เจ๋งจริง ๆ
    ถามว่าตั้งใจจะใช้ Elixir เป็นภาษาหลักไหม

    • ตอบว่า Elixir เป็นหนึ่งในตัวเลือกหลัก
      ส่วนตัวมั่นใจว่าจะทำงานกับมันได้สนุกกว่า C++ อย่างชัดเจน

    • สำหรับผมไม่ใช่ แต่ผมทำงานกับ Elixir มาเกือบ 9 ปี 2 เดือนแล้ว และก็ใช้ Rust กับ Golang ได้ด้วย
      เลยอยากรู้ว่าตอนนี้มีใครกำลังรับคนอยู่ไหม