Route gameCommand traffic through WebRTC unreliable DataChannel

Socket.IO (TCP) holds back later packets while it retransmits a lost
one, which stalls worldUpdate delivery on lossy long-distance links —
exactly the pattern game state suffers worst from. WebRTC DataChannels
in unreliable mode (ordered:false, maxRetransmits:0) drop late packets
instead of queueing them, which is what we want for high-frequency
state sync.

Adds a per-user WebRTCTransport on top of the existing Socket.IO
connection. Socket.IO stays in charge of bootstrap, signaling
(SDP/ICE exchange), and control messages — only gameCommand payloads
get routed onto the unreliable channel once it's open. If WebRTC
fails to negotiate, gameCommand transparently falls back to
Socket.IO, so the game keeps working unchanged.

A new StatsLogger writes per-session JSONL events (session_start,
webrtc_ready with negotiation time, per-second stats with transport,
RTT samples, recv/send rates, seq gaps) so we can compare real-world
runs (e.g. Germany server <-> Korea client) instead of guessing.
URL flag ?webrtc=0 forces fallback for A/B testing.

scripts/webrtc-browser-test.js spins up a headless Chromium against
a freshly-started server and asserts the unreliable channel opens
and gameCommand traffic actually rides it.
This commit is contained in:
Jeena 2026-05-11 00:38:18 +00:00
parent 47faae81e5
commit a0481ed867
9 changed files with 1412 additions and 138 deletions

View file

@ -17,16 +17,17 @@
},
"main": "server.js",
"dependencies": {
"socket.io": "^4.7.4",
"chart.js": "^4.4.0",
"express": "^4.18.2",
"node-datachannel": "^0.10.0",
"requirejs": "^2.3.6",
"screenfull": "^6.0.2",
"chart.js": "^4.4.0"
"socket.io": "^4.7.4"
},
"devDependencies": {
"nodemon": "^3.0.2"
"nodemon": "^3.0.2",
"playwright": "^1.59.1"
},
"optionalDependencies": {},
"engines": {
"node": ">=16.0.0"
},