WebSocket workbench
Open a real socket against the signaling service. Send validated frames, measure round-trip time, close with intent, and kill the connection to see the difference between a clean goodbye and a network failure.
Lesson 02 — WebSocket from the wire upMeasured round-trip
no samples
IN
0
OUT
0
LATEST
—
Frame log
0 ENTRIESNo frames yet. Connect, then send the echo preset.
01
Close codes are decisions
1000 and 1008 should stop reconnection. 1006 should trigger backoff. Never send 1005 or 1006.
02
Heartbeats prove the whole path
Protocol ping/pong detects a dead socket, but the browser hides it. The app-level ping proves the server is processing work.
03
Limits are part of the API
The server rejects frames over 16 KB in the playground and 64 KB elsewhere. The lesson is not to raise the limit blindly.
Completion
Record the WebSocket lab
Open the socket, send a frame, observe a close, and reconnect. Then save the lab to your browser's progress record.
Lab: do and don't
HARD-WON RULESDo
Close deliberately
Send 1000 when the user leaves and stop the reconnect loop. The server should clean up room membership immediately.
Keep a heartbeat with a deadline
Send an app ping on an interval and consider the socket dead when a pong is missing, not merely when TCP says it is open.
Validate on both sides
The browser validates the composer; the server validates every frame again. Never trust the client for schema, size, or rate limits.
Don't
Don't reconnect after every close
Policy and auth failures need a fix, not a retry. Inspect the code before scheduling another attempt.
Don't treat heartbeats as bandwidth tests
A 5-second ping is liveness evidence, not a quality metric. Use payload timing and server timestamps for latency.
Don't print unbounded logs forever
Every long-lived UI log needs a cap. This panel keeps 200 entries; production telemetry needs retention policy too.