WebSocket

In one line

WebSocket upgrades an ordinary HTTP request into a persistent, full-duplex connection, so server and client can push messages to each other the instant something happens.

The problem it solves

Plain HTTP is request/response: the client asks, the server answers, the connection closes. That's wrong for live data — a vitals dashboard would have to poll ("anything new? anything new?"), wasting requests and adding seconds of latency. WebSocket keeps one connection open so the server can push the instant a reading arrives.

How it works

• The client sends an HTTP request with Upgrade: websocket; after the handshake, the same TCP connection is repurposed to carry lightweight frames in both directions until either side closes it.
• vs HTTP polling — no per-request overhead, millisecond latency.
• vs MQTT — no broker, no topics, no QoS; just a pipe. (Many systems run MQTT over WebSocket so browsers can join broker traffic.)

Where it sits among real-time options

Need	Use
Request/response	HTTP/REST
Server → browser push	WebSocket (or Server-Sent Events for one-way)
Device fleets, pub/sub	MQTT
Audio/video peer-to-peer	WebRTC (WebSocket does its signalling)

Where it shows up in digital health

Live vital-sign dashboards, bed-board updates, chat in patient portals, WebRTC's signalling channel, and streaming AI responses token-by-token (Vaidya will use exactly this pattern). The rule of thumb: request/response → HTTP; server push to browsers → WebSocket; device fleets → MQTT.

Common pitfalls

• No reconnect/heartbeat logic — connections drop on flaky networks; clients must reconnect and resync.
• Scaling statefulness — open connections are server state; load-balancing and horizontal scaling need sticky sessions or a pub/sub backplane.
• Security — use wss:// (TLS), authenticate the upgrade, and authorise each message; an open socket is an attack surface.

Key takeaways

• WebSocket = one persistent, full-duplex connection, upgraded from HTTP.
• It replaces polling for true server-push: live vitals, alerts, chat, streaming AI.
• Pick it for browser push; MQTT for device fleets; WebRTC for media (it rides WebSocket).
• Plan reconnection, scaling, and wss:// security from the start.