Trystero - สร้างเว็บแอปมัลติเพลเยอร์ได้ทันทีโดยไม่ต้องมีเซิร์ฟเวอร์

• ไลบรารีที่ช่วยให้สร้าง เว็บแอปมัลติเพลเยอร์ ที่ เชื่อมต่อกันได้โดยไม่ต้องมีเซิร์ฟเวอร์ ด้วยโค้ดเพียงไม่กี่บรรทัด
• ทำงานบนพื้นฐานของ WebRTC ในเบราว์เซอร์ และใช้เครือข่ายสาธารณะเป็น ช่องทางแลกเปลี่ยนสัญญาณ (signaling) เพื่อ ทำให้การจับคู่และการสื่อสารแบบ P2P เป็นอัตโนมัติ
  • เลือกใช้ BitTorrent, Nostr, MQTT, IPFS, Supabase, Firebase อย่างใดอย่างหนึ่งเพื่อ ค้นหาเพียร์ได้โดยไม่ต้องมีเซิร์ฟเวอร์
  • หลังจาก signaling แล้ว ข้อมูลของแอป จะถูกส่งต่อแบบ P2P พร้อม การเข้ารหัส E2E โดยไม่ผ่านตัวกลาง
• มี abstraction ระดับสูง สำหรับ Rooms/การบรอดแคสต์, การ serialize อัตโนมัติ, การแบ่งชิ้น/การ throttle สำหรับข้อมูลขนาดใหญ่, อีเวนต์ความคืบหน้า, การเข้ารหัสข้อมูลเซสชัน, เมทาดาทาของสตรีม เป็นต้น
• ไม่ได้ทำงานแค่ในเบราว์เซอร์ แต่ยังรองรับ Node/Deno/Bun และมีความสามารถที่ใช้ได้จริง เช่น การตั้งค่า TURN server, React hooks, การรันฝั่งเซิร์ฟเวอร์
• แนวทางที่ใช้โครงสร้างพื้นฐานสาธารณะได้แบบ ไม่ต้องตั้งค่า ทำให้เหมาะกับการทดลองและการทำต้นแบบหลากหลายรูปแบบ

• เดโมไซต์ - https://oxism.com/trystero ลองเปิดพร้อมกัน 2 แท็บแล้วขยับ/คลิกเมาส์ ก็จะเห็นการทำงานได้ทันที
• ดูสิ่งที่ผู้คนกำลังสร้างด้วย Trystero - Awesome Trystero

[kimjoin2]

แล้วเซิร์ฟเวอร์ TURN นี่บรรพบุรุษจะเป็นคนจัดหาให้เหรอ?

[helio]

มี 'stun:stun.cloudflare.com:3478' ถูกฝังไว้ในซอร์สเลยนะ

[kimjoin2]

ไม่ใช่ stun แต่เป็น turn ครับ
stun แค่บอกประมาณว่าเกณฑ์ของ stun แล้วคุณคือใคร เลยพอจะมีเซิร์ฟเวอร์สาธารณะให้ใช้บ้าง
แต่ turn ต้องคอยรีเลย์ทราฟฟิกให้ (ซึ่งแพง) เลยต้องไม่จ่ายเงินใช้ หรือไม่ก็ต้องติดตั้งเองครับ
ตัวอย่าง) https://github.com/coturn/coturn
ประมาณเจ้าตัวนี้แหละครับ

แม้จะมีหลายกรณีที่สื่อสารกันได้ด้วย stun อย่างเดียว แต่ถ้าจะพูดแบบง่าย ๆ ว่า "ได้" เลยก็คงจะ.....
มัน......ก็ได้แหละ..... แต่ก็ อืม.. ประมาณนั้นครับ

[skageektp]

ถ้าเป็นการจับคู่แบบ p2p ก็ไม่จำเป็นต้องใช้ TURN ไม่ใช่เหรอ

[kimjoin2]

คงขึ้นอยู่กับเจตนาที่คุณพูดถึงว่าเป็น "การจับคู่ p2p" ใน WebRTC แบบไหน

1. อยู่ในสถานะที่สามารถสื่อสารแพ็กเก็ตกันผ่าน UDP ได้ทั้งสองฝ่าย
2. อยู่ในสถานะที่รู้เพียงแค่ที่อยู่ที่ STUN บอกให้กันและกัน

ถ้าเป็นข้อ 1 ก็ไม่จำเป็นต้องใช้ TURN อย่างที่คุณบอกครับ
แม้ในข้อ 2 ถ้าสถานการณ์เอื้อและทั้งสองฝ่ายสื่อสารกันผ่าน UDP สำเร็จ ก็ไม่จำเป็นต้องใช้ TURN

ในข้อ 2 ถ้าทั้งสองฝ่ายส่งแพ็กเก็ตผ่าน UDP หากันไม่สำเร็จ จึงจำเป็นต้องใช้ TURN

ปัจจัยที่ทำให้ล้มเหลว เช่น

• ฝั่ง peer อยู่หลัง symmetric NAT ทำให้ใช้ที่อยู่ (หรือพอร์ต) ที่ STUN หาเจอไม่ได้
• มีจุดใดจุดหนึ่งระหว่างทางของเครือข่ายที่อนุญาตเฉพาะเว็บทราฟฟิก (80, 443)
• มีจุดใดจุดหนึ่งระหว่างทางของเครือข่ายที่บล็อก UDP
• ฝั่งหนึ่งใช้ได้แค่ IPv4 แต่อีกฝั่งใช้ได้แค่ IPv6
• ฯลฯ

กรณีแบบนี้ต้องใช้ TURN ครับ

(เพิ่งรู้ตอนทบทวนความจำเหมือนกันว่า IPv4 only <-> IPv6 only ใช้งานกันไม่ได้)

[skageektp]

ใช่ ก็คือข้อ 2 นั่นแหละ บอกว่าเป็น 'การเชื่อมต่อกันได้โดยไม่ต้องมีเซิร์ฟเวอร์', 'ไลบรารี' แต่คุณคาดหวังกันมากเกินไปหรือเปล่า...

[kimjoin2]

หมายถึงส่วนไหนที่คุณต้องการจะสื่อครับ?

1. สามารถเชื่อมต่อกันได้ด้วยแค่ที่อยู่ (+พอร์ต) ที่ได้จาก STUN ดังนั้นจึงไม่จำเป็นต้องมีเซิร์ฟเวอร์ TURN เพราะฉะนั้นคำว่า "เชื่อมต่อกันโดยไม่มีเซิร์ฟเวอร์" ก็ตรงตามข้อความนั้นเลย
   -> ถ้าเป็นกรณีนี้ สงสัยว่าความรู้ที่ผมมีคงเก่าแล้ว ถ้ามีส่วนที่สถานการณ์เปลี่ยนไปหลังจากข้อมูลที่ผมรู้ (และแชร์ไว้) รบกวนช่วยบอกให้หน่อยนะครับ~!
2. ยังจำเป็นต้องมีเซิร์ฟเวอร์ TURN แต่เพราะเป็นไลบรารี ก็ขออนุโลมระดับนั้นได้
   -> ที่คุณ skageektp พูดมาถูกต้องครับ เพราะเป็นไลบรารี ก็อาจอนุโลมได้ประมาณนั้น ผมเองแค่ไวเกินไปครับ

ส่วนผม
3. ถ้าจะใช้งานให้ถูกต้อง แค่ STUN อย่างเดียวไม่พอและต้องมี TURN แต่พูดเกินจริงไปมาก~
กำลังจะสื่อแบบนี้อยู่ครับ.

[kimjoin2]

สำหรับคำอธิบายข้อ 1 และ 2

1. สถานะที่สามารถสื่อสารแพ็กเก็ตผ่าน UDP ระหว่างกันได้ -> สถานะที่แต่ละ peer สามารถสื่อสารแพ็กเก็ตผ่าน UDP ระหว่างกันได้
2. สถานะที่รู้เพียงที่อยู่ที่ STUN บอกให้ของกันและกัน -> สถานะที่แต่ละ peer รู้เพียงที่อยู่ที่ STUN บอกให้ของกันและกัน

ขอแก้ไขเป็นดังนี้ ในต้นฉบับเดิมมีส่วนที่อาจทำให้เข้าใจผิดได้ครับ