Server Behavior

Sessions

Pub/Sub sessions are associated with active and recently active sockets. When a client connects, the server will attempt to restore the prior session if the client supplies a session ID. If the client does not supply a session ID, or the session has expired, the server will create a new session, and supply the new session ID to the client when requested.

Session Restore

If a client supplies a read (subscribe) key on connect, and they have requested their session UUID at least once, then their session will be persisted. A persisted session is updated on each subscribe or unsubscribe event (including unsubscribe-all). This allows the client's subscriptions to be restored on successful session resume.

A session restore is attempted by the server if the client populates the session_uuid field in the Payload header on connect. If the server is able to find a session with the same UUID associated with the same project as the newly authenticated client, then the session will be resumed, including all subscriptions which were held when the client was disconnected.

The client can determine whether their session was replaced by comparing the result of a session UUID fetch with the UUID they supplied on connect. This is built in to all official SDKs, and when the session is replaced, a session replacement event is emitted, to alert the client to the fact that their subscriptions have not been restored.

Session Expiration

When a read (subscriber) client's connection is lost (whether initiated by the client or service disruption), the client has a "grace period" of 5 minutes during which they can reconnect and resume their prior session. If they reconnect after 5 minutes have elapsed, their session will automatically expire, and their subscriptions will be lost.

After a connection loss, the official SDKs will automatically attempt to reconnect with a exponential backoff applied.

Limits

Services must apply limits in order to prevent abuse (whether intentional or accidental).

Max Message Size

The maximum size of Pub/Sub message is 64kB. Keep in mind, this is bytes, not characters. Since the encoding for JSON is UTF-8, traditional latin characters (standard ASCII) will be encoded with a single byte. Those characters which are not a subset of ASCII may consume substantially more space. Therefore a simple count on the size of a string is insufficient to determine if a messages is too large. A good practice is to keep message sizes under 10k characters, and you should never have a problem. This will keep delivery latencies lower as well.

If a message is larger than the maximum allowed size, the client connection will be terminated.