Broker deep dive

Broker is a component of AnyCable-Go responsible for keeping streams, sessions and presence information in a cache-like storage. It drives the Reliable Streams and Presence features.

Broker implements features that can be characterized as hot cache utilities:

  • Handling incoming broadcast messages and storing them in a cache—that could help clients to receive missing broadcasts (triggered while the client was offline, for example).
  • Persisting client states—to make it possible to restore on re-connection (by providing a session id of the previous connection).
  • Keeping per-channel presence information.

Client-server communication

Below you can see the diagram demonstrating how clients can use the broker-backed features to keep up with the stream messages and restore their state:

ClientServerRPCPublisherNo RPC calls made hereNo need to re-subscribe, we only request history'{"stream":"chat_42","data":{"text":"Hi"}}'CONNECT /cableConnectSUCCESS'{"type":"welcome","sid":"a431"}''{"command":"subscribe","identifier":"ChatChannel/42","history":{"since":163213232}}'SubscribeSUCCESS'{"type":"confirm_subscription"}}''{"message":{"text":"Hi"},"stream_id":"chat_42",offset: 42, epoch: "y2023"}''{"type":"confirm_history"}''{"stream":"chat_42","data":{"text":"What's up?"}}''{"message":{"text":"What's up?"},"stream_id":"chat_42",offset: 43, epoch: "y2023"}'DISCONNECTDisconnect'{"stream":"chat_42","data":{"text":"Where are you?"}}'CONNECT /cable?sid=a431'{"type":"welcome", "sid":"h542", "restored":true,"restored_ids":["ChatChannel/42"]}''{"type":"history","identifier":"ChatChannel/42","history":{"streams": {"chat_42": {"offset":43,"epoch":"y2023"}}}}''{"message":{"text":"Where are you?"},"stream_id":"chat_42",offset: 44, epoch: "y2023"}''{"type":"confirm_history"}'ClientServerRPCPublisher

To support these features, an extended Action Cable protocol is used for communication.

You can use AnyCable JS client library at the client-side to use the extended protocol.

Broadcasting messages

Broker is responsible for registering broadcast messages. Each message MUST be registered once; thus, we MUST use a broadcasting method which publishes messages to a single node in a cluster (see broadcasting). Currently, http and redisx adapters are supported.

NOTE: When legacy adapters are used, enabling a broker has no effect.

To re-transmit registered messages within a cluster, we need a pub/sub component. See Pub/Sub for more information.

The overall broadcasting message flow looks as follows:

Node 1
Node 2
Message
Message
Cache Message
Registered Message
Registered Message
Registered Message
Registered Message
Registered Message
Broadcaster
Broker
Broker Backend
Pub/Sub
Client A
Client B
Pub/Sub 2
Client C
Client D
Publisher