Recovering after a disconnection

When reconnecting to the gateway, clients should resubscribe to all desired symbols. In order to avoid missing data after a reconnection, there are three main approaches to recovery:

  • Natural refresh
  • Intraday replay
  • Snapshot (MBO only)

The best approach to recovery will depend on the client's use case and specific needs.

Natural refresh

To recover via natural refresh, clients can resubscribe to all desired symbols without the start or snapshot parameters. This means no data will be replayed, and the client will immediately receive the newest messages upon subscribing.

This recovery approach is the fastest (since there's no data replay), and is recommended for stateless schemas such as MBP-10, in cases where the client only requires the current state of each instrument.

Intraday replay

To recover via intraday replay, clients should store the last ts_event and the number of records received with that last timestamp, per schema and instrument. The ts_event and record count should be continuously updated when processing incoming records.

When reconnecting, clients should set the start parameter of the resubscription to the lowest stored ts_event across all instruments for that schema. The gateway will then send all records starting from that timestamp (including records with the exact same ts_event).

The resubscription may lead to duplicated data being sent to the client. Clients who require that each message is delivered exactly once are instructed to:

  • Discard all records with a lower ts_event than the stored one for the corresponding instrument
  • Discard the first N records with the same ts_event as the stored one for the corresponding instrument, where N is the number of records already seen with that ts_event prior to the disconnection. This is important in case there are multiple events with the same ts_event and the client is disconnected halfway through processing those events

This recovery approach is recommended when clients require the uninterrupted history of records for the desired schema (for example, when using the Trades schema to construct a ticker tape). However, this approach can take a longer time to synchronize with the live stream, depending on how long the client was disconnected.

For the CBBO and BBO schemas where filtering is based on ts_recv, clients should store the last ts_recv per instrument. When reconnecting, clients should set the start parameter of the resubscription to the lowest stored ts_recv across all instruments. The gateway will then send all records starting from that timestamp (including records with the same ts_recv). Since CBBO and BBO are stateless schemas, you should always refer to the most recent record per instrument.

Snapshot (MBO only)

When resubscribing to the MBO schema, clients can request a snapshot to receive the current state of the book after a disconnection. This eliminates the need to replay the missed messages and leads to faster synchronization with the live stream. This recovery approach is generally recommended over intraday replay when using the MBO schema.