Expand description
One WebSocket per Massive cluster, shared by every stream a
MassiveSubscriber and its clones open on it.
§Why the connection is shared
Massive allows a key a fixed number of WebSocket connections per cluster — stocks, options,
forex, crypto and the rest each count separately — one on an individual plan. Past the limit it
does not refuse the new connection: on every cluster measured it closes an older one, with a
max_connections status, and the newcomer keeps streaming. One socket per stream could
therefore never stream two kinds from one cluster at once.
§Shape
A task per cluster owns that cluster’s socket. Each stream attaches to it and is handed a
MassiveAttachment: the frames carrying its own subscriptions, which it parses exactly as it
would parse a socket of its own.
Massive packs messages for several channels and markets into one frame, a JSON array, so the
connection splits frames: it reads only each message’s channel, ev, and its market, and a
stream receives a frame of only its own messages.
- Connect lazily, close when idle. A cluster’s socket opens on its first attach and closes once no stream remains attached to it.
- Subscribe once per channel and market. A subscription the socket already holds is not sent again — Massive would not answer it — and its messages reach every stream holding it.
- Unsubscribe on the last detach. Dropping an attachment unsubscribes everything no other stream holds.
- One subscribe at a time. Massive confirms each subscription by name, but refuses one with
a bare
not authorizednaming none, so a refusal belongs to the subscribe in flight. Attaches and detaches are therefore serialised; frames keep flowing to every attached stream meanwhile. - Pinged. Massive drops sockets without a close, nightly among other times, so the
connection pings every
KEEPALIVEand treats a socket silent since the last ping as lost.
§What Massive does not answer
Massive says nothing at all to a subscription for a channel it does not publish, so an attach
naming one waits out its timeout, and the timeout names what was never confirmed, in
SocketError::Unacknowledged. It confirms a
subscription to a market it does not list, and then publishes nothing for it: a misspelt
market is indistinguishable from a quiet one.
§Reconnect
Every stream on a socket ends together when it is lost, and each is re-initialised by the usual reconnect wrapper. The first to re-attach reconnects and re-subscribes everything the lost socket held; the rest re-attach to that one reconnect. Massive replays nothing, so what it published while no socket was open is missed.
A stream keeps its place for REATTACH_GRACE after the socket is lost; frames for a stream
that has not re-attached yet are held until then, and discarded with a warning if it has not.
§Sharing is by clone, and only by clone
Clones of one subscriber share one connection per cluster. A second subscriber built separately
for the same key, or another process, opens a second socket, and Massive closes the older one.
Its streams reconnect — closing the other in turn. The warning logged for each lost connection
quotes Massive’s max_connections status verbatim, so the contest can be recognised; the
library does not back off from it.
Structs§
- Massive
Attachment - One stream’s view of a Massive cluster’s shared connection.
Constants§
- KEEPALIVE
- How often the connection pings Massive.
- REATTACH_
GRACE - How long a shared connection keeps a stream’s place after the socket it was reading is lost.