Trystero ไลบรารี JavaScript ที่สัญญาว่าจะทำให้เว็บไซต์ใดๆ กลายเป็นแบบผู้เล่นหลายคนด้วยโค้ดเพียงไม่กี่บรรทัด ได้รับความสนใจจากแนวทางที่เรียบง่ายในการเชื่อมต่อแบบ peer-to-peer อย่างไรก็ตาม การทดสอบจากชุมชนได้เผยให้เห็นข้อจำกัดที่สำคัญซึ่งอาจส่งผลกระทบต่อการใช้งานจริงในแอปพลิเคชันเชิงผลิต
ไลบรารีนี้ช่วยให้นักพัฒนาสามารถสร้างประสบการณ์ผู้เล่นหลายคนแบบเรียลไทม์โดยใช้เทคโนโลยี WebRTC เชื่อมต่อผู้ใช้โดยตรงโดยไม่ต้องใช้เซิร์ฟเวอร์เฉพาะ ผู้ใช้สามารถซิงค์การเคลื่อนไหวของเมาส์ การคลิก และการโต้ตอบอื่นๆ ได้โดยการเข้าร่วมห้องและส่งสัญญาณการกระทำไปยังผู้ใช้อื่นที่เชื่อมต่ออยู่
วิธีการส่งสัญญาณที่รองรับ:
- BitTorrent
- Nostr
- MQTT
- IPFS
- Supabase
- Firebase
ความกังวลเรื่องการขยายตัวเกิดขึ้นระหว่างการทดสอบ
สมาชิกชุมชนค้นพบอย่างรวดเร็วว่า Trystero มีปัญหากับการเชื่อมต่อหลายรายการพร้อมกัน ผู้ใช้รายงานข้อผิดพลาดในคอนโซลเบราว์เซอร์ที่ระบุว่า Failed to construct 'RTCPeerConnection': Cannot create so many PeerConnections เมื่อผู้ใช้จำนวนมากพยายามเข้าร่วมห้องเดียวกัน ข้อจำกัดนี้เกิดจากการออกแบบโดยธรรมชาติของ WebRTC ที่ผู้เข้าร่วมแต่ละคนต้องรักษาการเชื่อมต่อแยกกับผู้เข้าร่วมคนอื่นๆ ทุกคนในห้อง
สถาปัตยกรรมแบบ peer-to-peer หมายความว่าความต้องการการเชื่อมต่อเพิ่มขึ้นแบบเลขชี้กำลังตามจำนวนผู้ใช้ สำหรับกลุ่มใหญ่ นักพัฒนาจะต้องใช้เซิร์ฟเวอร์ SFU (Selective Forwarding Unit) ซึ่งขัดแย้งกับคำสัญญาแบบไร้เซิร์ฟเวอร์ของไลบรารี
WebRTC: Web Real-Time Communication เทคโนโลยีที่ช่วยให้สามารถสื่อสารระหว่างเบราว์เซอร์กับเบราว์เซอร์โดยตรงSFU: สถาปัตยกรรมเซิร์ฟเวอร์ที่รับสตรีมจากผู้เข้าร่วมและส่งต่อไปยังผู้อื่น ลดภาระการเชื่อมต่อแยกของแต่ละคน
ข้อจำกัดทางเทคนิคที่สำคัญ:
- ไม่สามารถจัดการการเชื่อมต่อแบบ peer-to-peer หลายรายการพร้อมกันได้
- การเชื่อมต่อเพิ่มขึ้นแบบเลขชี้กำลังตามจำนวนผู้ใช้
- ต้องใช้เซิร์ฟเวอร์ SFU สำหรับกลุ่มขนาดใหญ่
- ยังคงต้องพึ่งพาเซิร์ฟเวอร์ signaling จากบุคคลที่สาม
ปัญหาความเข้ากันได้ของเบราว์เซอร์เกิดขึ้น
การทดสอบในเบราว์เซอร์ต่างๆ เผยให้เห็นประสิทธิภาพและฟังก์ชันการทำงานที่ไม่สม่ำเสมอ ในขณะที่ไลบรารีทำงานได้อย่างราบรื่นใน Chrome ผู้ใช้ Firefox ประสบปัญหาความล่าช้าและประสิทธิภาพที่สำคัญ ผู้ใช้ Safari รายงานปัญหาที่รุนแรงยิ่งขึ้น โดยบางคนประสบกับการขัดข้องของเบราว์เซอร์อย่างสมบูรณ์หลังจากฟังก์ชันการทำงานเริ่มต้น
ปัญหาความเข้ากันได้เหล่านี้เน้นย้ำถึงความท้าทายของการใช้งาน WebRTC ข้ามเบราว์เซอร์ ที่เบราว์เซอร์ต่างๆ จัดการการเชื่อมต่อ peer และสตรีมสื่อด้วยระดับความสำเร็จที่แตกต่างกัน
ปัญหาความเข้ากันได้ของเบราว์เซอร์:
- Chrome : ทำงานได้อย่างราบรื่น
- Firefox : มีปัญหาความล่าช้าและประสิทธิภาพอย่างมาก
- Safari : มีปัญหาการทำงาน อาจเกิดการค้างหรือหยุดทำงานของเบราว์เซอร์
ผลกระทบด้านกฎระเบียบสำหรับฟีเจอร์ผู้เล่นหลายคน
ประเด็นการอภิปรายที่ไม่คาดคิดเกิดขึ้นเกี่ยวกับการปฏิบัติตามกฎหมายสำหรับเว็บไซต์ที่มีฟีเจอร์การโต้ตอบระหว่างผู้ใช้ ภายใต้กฎระเบียบล่าสุดของ UK เว็บไซต์ที่ช่วยให้มีการสื่อสารโดยตรงระหว่างผู้ใช้อาจเผชิญกับข้อกำหนดเพิ่มเติม รวมถึงระบบยืนยันอายุที่อาจเกิดขึ้นและความรับผิดชอบในการควบคุมเนื้อหา
เพียงแค่เตือนว่าฟีเจอร์การโต้ตอบระหว่างผู้ใช้แบบนี้ทำให้เว็บไซต์ของคุณเป็น 'เครือข่ายสังคม' ตามกฎระเบียบของ UK และดังนั้นคุณต้องได้สำเนาบัตรประจำตัวของรัฐบาลจากผู้ใช้เพื่อที่คุณจะสามารถปฏิเสธการเข้าถึงหากพวกเขาอายุน้อยกว่ากำหนด
ภูมิทัศน์กฎระเบียบนี้เพิ่มความซับซ้อนสำหรับนักพัฒนาที่พิจารณาฟีเจอร์ผู้เล่นหลายคน เนื่องจากพวกเขาต้องสร้างสมดุลระหว่างการใช้งานทางเทคนิคกับข้อกำหนดการปฏิบัติตามกฎหมาย
ข้อจำกัดของสถาปัตยกรรมทางเทคนิค
แม้จะทำการตลาดว่าเป็นแบบไร้เซิร์ฟเวอร์ Trystero ยังคงพึ่งพาบริการของบุคคลที่สามสำหรับการส่งสัญญาณ SDP ซึ่งช่วยอำนวยความสะดวกในการเชื่อมต่อเริ่มต้นระหว่าง peer ไลบรารีรองรับวิธีการส่งสัญญาณต่างๆ รวมถึง BitTorrent, MQTT, IPFS และบริการคลาวด์เช่น Firebase และ Supabase
แนวทางไร้เซิร์ฟเวอร์ที่แท้จริงมีอยู่ เช่น การค้นหา peer ที่ใช้ QR code แต่สิ่งเหล่านี้มีการใช้งานจริงที่จำกัดเนื่องจากข้อจำกัดการหมดเวลาของเบราว์เซอร์และความท้าทายด้านการใช้งาน
*SDP: Session Description Protocol ใช้เพื่อเจรจาพารามิเตอร์การเชื่อมต่อระหว่าง peer
แม้ว่า Trystero จะเสนอจุดเริ่มต้นที่น่าสนใจสำหรับนักพัฒนาที่สนใจแอปพลิเคชันเว็บแบบ peer-to-peer ความคิดเห็นจากชุมชนเผยให้เห็นว่าการใช้งานเชิงผลิตต้องการการพิจารณาอย่างรอบคอบเกี่ยวกับข้อจำกัดการขยายตัว ความเข้ากันได้ของเบราว์เซอร์ และข้อกำหนดด้านกฎระเบียบ ไลบรารีอาจทำงานได้ดีสำหรับการสาธิตขนาดเล็กหรือประสบการณ์ผู้เล่นหลายคนแบบง่าย แต่แอปพลิเคชันขนาดใหญ่น่าจะต้องการโซลูชันโครงสร้างพื้นฐานที่แข็งแกร่งกว่า