WebSocket resilience
Validate six application heartbeat echoes continuously or across one deliberate clean close and fresh connection.
Checking network test availability…
Check heartbeat replies and a deliberate reconnect
This uses our existing signed WebSocket echo endpoint. It sends small application messages, not protocol ping/pong frames. No connection opens until you start the check.
After replies 1–3, this client requests normal closure and verifies the close event. It waits 500 ms, opens one fresh socket, then checks replies 4–6. Unexpected failures are not automatically retried.
- Heartbeat exchanges
- 6, one at a time
- Connect deadline
- 3 seconds
- Reply deadline
- 2 seconds
- Run deadline
- 20 seconds, plus cleanup
Each message is capped at 256 UTF-8 bytes. A 250 ms observation interval follows each reply, including the last; clean closure has a 1.5 s deadline. The existing 8 MiB admission allowance is reserved, not transmitted. Stop closes owned sockets and requests session revocation.
What this result establishes
A verified result means six exact replies were observed in the declared sequence before orderly closure within this bounded scenario. It is not an exactly-once delivery guarantee for another application, and it does not test in-flight message replay.
The native browser manages its WebSocket handshake and may attach ambient cookies. This tool uses short-lived signed session capabilities in the existing subprotocol envelope, never in a URL or exported report. It accepts no target address or user payload.