WebSockets
Most important commands to remember
websocat -s ADDRESS:PORT— run a small local WebSocket server.websocat ws://…— connect an interactive client.
Commands and flags
| Option or key | Meaning |
|---|---|
-s 127.0.0.1:8765 |
Listen as a server only on IPv4 loopback port 8765. |
ws://127.0.0.1:8765 |
Connect without TLS to that local WebSocket endpoint. |
Enter |
Send the typed line in websocat’s interactive text mode. |
Ctrl+C |
Stop the client or server in its own terminal. |
The first block belongs in terminal A, the second in terminal B. This is a local text exchange, not a production server.
The concepts that matter
1. A connection stays open for messages in both directions
WebSocket supports bidirectional communication over a persistent connection. Once established, either side can send messages without waiting for a new HTTP request for each update.
This suits interactive notifications, collaboration, or control traffic. It changes the interaction pattern, not the need for authentication or capacity planning. Every open connection still consumes resources somewhere.
2. An opening handshake is different from message traffic
The classic WebSocket handshake begins with an HTTP/1.1 upgrade exchange. After successful switching, WebSocket frames carry messages. A successful ordinary GET to the same server does not prove that it accepts WebSocket upgrades.
The ws scheme is unencrypted; wss uses TLS. A proxy in the path must support the connection’s upgrade or relevant protocol mechanism and its long-lived traffic.
3. Messages have boundaries but may use multiple frames
WebSocket supports text and binary messages. A message can be split across frames; applications should not confuse frame boundaries with their own business records. Client masking is a protocol mechanism, not encryption.
Ping, pong, and close are control frames. They help manage the connection, but a pong alone does not prove that an application has processed a particular command. Application acknowledgments remain separate.
4. Reconnecting does not automatically restore application state
Connections can end through network changes, idle timeouts, proxy policy, or process failure. Reopening one does not automatically replay missed events or tell the client whether its last command completed.
Applications need sequence identifiers, resume rules, duplicate handling, and suitable backpressure where required. A slow recipient must not cause unlimited buffering. The persistent transport provides a channel, not durable event storage.
One small example
Optional: start the first command in terminal A. Once it is listening, run the second in terminal B. Leave both open.
websocat -s 127.0.0.1:8765websocat ws://127.0.0.1:8765In terminal B, type hello and press Enter. Look for that line in terminal A. Then type reply in terminal A and press Enter; inspect terminal B. These are messages you supply, not pre-recorded output. Neither side automatically echoes your text in this setup.
If port 8765 is occupied, do not stop the unrelated process. Use a free local port consistently in both commands. A refused connection means the server is not reachable at the specified endpoint; it does not reveal a message-framing problem.
Finish by pressing Ctrl+C in both terminals. The sockets close and no files remain.
Keep this idea: WebSocket keeps a bidirectional message channel open; delivery recovery and application success still belong to your protocol.