An in-depth update regarding the temporary outage of XMCL's Peer-to-Peer (P2P) online multiplayer service, how the launcher interacts with xmcl-web-api, why Deno API limits were exhausted, and our current backend migration.
Status Update: P2P Multiplayer Service Downtime & Backend Migration
SERVICE NOTICE
P2P Online Room Hosting is Temporarily Unavailable. When attempting to create or join P2P rooms in XMCL, you may encounter multiplayer_room_request_failed or WebSocket connection errors. Local LAN play and joining dedicated servers remain 100% functional.
Overview
Over the past few days, many players have reported that creating or joining online multiplayer rooms through XMCL is currently failing.
We want to provide full transparency by explaining how XMCL's P2P multiplayer system works behind the scenes, how the launcher communicates with our backend (xmcl-web-api), why changes in Deno Deploy's free tier quotas caused this service interruption, and how we are fixing it.
How XMCL P2P Multiplayer Works
XMCL's P2P multiplayer allows players to host single-player Minecraft worlds and open them to friends over the internet without port forwarding, external server hosting, or third-party VPN tools like Hamachi.
+------------------+ Signaling & Ticket Broker +------------------+
| | (https://api.xmcl.app / Web-API) | |
| Host Launcher | <======== WebSocket Control ========> | Guest Launcher |
| | (SDP & ICE Exchange) | |
+------------------+ +------------------+
| |
+================ Direct P2P WebRTC Connection ===============+
(Host-Star DataChannel Mesh)1. Launcher Architecture & xmcl-web-api
The launcher (xmcl-electron-app) uses @xmcl/wrtc-multiplayer and PeerService to manage room life-cycles and peer connections:
- Host Room Creation: The host issues a request to
POST /v2/multiplayer/rooms. The backend validates the player's XMCL session token and issues a 5-minute single-use admission ticket and WebSocket URL. - Control Socket: The host opens a persistent control WebSocket (
GET /v2/multiplayer/rooms/:roomId/socket?ticket=...). - Guest Admission: Guests request an admission ticket via
POST /v2/multiplayer/rooms/:roomId/joinand connect via WebSocket to exchange WebRTC offer/answer SDP payloads and ICE candidates. - Direct P2P DataChannels: Once SDP negotiation finishes, guests close their temporary WebSocket connection. All Minecraft game traffic and mod/file transfers flow directly between peers via WebRTC DataChannels and a local virtual port bridge (
http://localhost:25566/files/...). Game traffic is never relayed through the web API servers.
2. Network Topology: Host-Star Mesh
Rather than forcing every guest to connect to every other guest, XMCL uses an efficient Host-Star topology:
- The Host maintains a persistent control socket to accept new guest handshakes immediately.
- Guests establish WebRTC links exclusively with the host.
- STUN/TURN servers (
/rtc/official) assist in discovering public IP addresses and traversing complex home NATs/routers (via UPnP / NAT-PMP).
The Root Cause: Deno API Quotas & Limit Exhaustion
Our primary public deployment of xmcl-web-api relied on Deno Deploy (using Deno KV and native WebSocket BroadcastChannel signaling).
Recently, Deno instituted strict platform policy updates and reduced free-tier quotas across Deno Deploy and Deno KV:
- Exponential User Growth: As XMCL's player base expanded, the sheer volume of daily WebSocket room creations, authorization tickets, and real-time signaling exchanges increased dramatically.
- Quota Exhaustion: The total API usage generated by active P2P multiplayer sessions surpassed 100% of all Deno free-tier limits.
- API Rejection: Deno Deploy began rejecting incoming
/v2/multiplayer/roomsAPI requests and closing WebSocket connections.
Because the signaling server acts as the essential "handshake broker" required for WebRTC peers to exchange ICE candidates and establish direct connections, room creation became unavailable worldwide.
What We Are Doing: Migration to Cloudflare Durable Objects
We are actively completing a major architectural migration of xmcl-web-api away from Deno Deploy to Cloudflare Workers with MultiplayerRoom Durable Objects.
Why Cloudflare Durable Objects?
- Global High Availability: Durable Objects provide stateful, low-latency WebSocket signaling nodes globally distributed across Cloudflare's edge network.
- Zero Third-Party Quota Blocks: Eliminates the strict free-tier API rate limits that broke the Deno deployment.
- Enhanced Security: Admission tickets (
XMCL_MULTIPLAYER_TICKET_SECRET) expire after 5 minutes and single-use validation prevents room hijacking. - Improved TURN Infrastructure: Expanded STUN/TURN relay server pools for higher NAT traversal success rates.
What Players Should Do
PLEASE WAIT PATIENTLY
We kindly ask all players to please wait and be patient while we complete the backend migration and deploy the new signaling infrastructure.
While online P2P room hosting is being restored:
- 📶 Local Area Network (LAN) Play: Playing with friends on the same physical Wi-Fi or home network operates via local multicast/ssdp discovery and remains 100% functional.
- 🌐 Dedicated Minecraft Servers: Joining standard public or private Minecraft servers via IP address or domain is completely unaffected.
Announcement Channels
Once the new Cloudflare Durable Objects backend is fully deployed and verified, we will immediately announce service restoration on our official communication channels:
- 📰 XMCL Blog: Updates and post-mortems will be published directly here in our journal.
- 💬 Community Channels: Announcements will be posted in our Discord server and Reddit community.
(Note: Official status announcements are published via our blog and social channels rather than GitHub repository issues).
We sincerely apologize for the disruption to your multiplayer gaming sessions. Thank you for your patience, support, and understanding while we upgrade our infrastructure!