Multicast Feeds, Sequence Gaps And Recovery

An exchange needs to send every order-book update to thousands of subscribers at once, and sending a separate copy of each message to each subscriber over its own connection would multiply the exchange's outbound bandwidth by the number of subscribers — completely impractical at the message rates modern markets produce. Multicast solves this by sending one copy of each packet onto the network, and letting network switches replicate it to every subscriber who has asked to listen on that channel. It's the difference between mailing a letter to each of ten thousand people versus reading an announcement over a loudspeaker that everyone in the room hears simultaneously — vastly more efficient, but with a real cost: nobody gets a personal confirmation that they heard it.

Why gaps happen and how they're numbered

Every message an exchange publishes carries a sequence number that increments by exactly one each time, so a subscriber always knows the expected number of the next message. Multicast, unlike a normal point-to-point network connection, doesn't guarantee delivery — packets can be dropped by an overloaded switch, corrupted in transit, or simply lost, and there's no automatic retransmission built into the protocol the way there is for an ordinary web connection. When a subscriber's next received sequence number jumps from, say, 4,417 to 4,420, it knows immediately that messages 4,418 and 4,419 are missing — a gap — and that its local copy of the order book is now out of date until it fills that gap.

Exchanges anticipate this and provide a recovery channel: either a separate multicast stream that periodically re-broadcasts a recent window of messages, or a request-response service where a subscriber can ask "please resend messages 4,418 through 4,419" and get them back directly. A well-built market-data handler treats gap detection and recovery as a first-class part of the system, not an edge case, because gaps happen constantly at the message rates busy symbols produce during volatile opens and closes.

Worked example: what a two-message gap costs

Suppose a book-rebuilding system detects sequence numbers 4,417 then 4,420 arriving 200 microseconds apart, and the recovery service takes 3 milliseconds round-trip to supply the missing messages 4,418 and 4,419. During those 3 milliseconds, any trading decision made from the local book is working off potentially stale top-of-book prices — if message 4,418 was a large order added at the best bid and 4,419 canceled the previous best offer, a strategy trading during the gap could be quoting or hitting against a picture of the book that no longer exists. The standard defensive practice is to mark the book "stale" the instant a gap is detected and refuse to act on it — accepting the opportunity cost of 3 milliseconds of inaction rather than the larger risk of trading on wrong information.

What this means in practice

Any system consuming a direct exchange feed — not just HFT firms — needs sequence-gap detection and a recovery path, because multicast's efficiency comes precisely at the cost of guaranteed delivery. Firms that skip this and simply trust every packet arrives will, sooner or later during a busy trading session, trade off a silently corrupted book, which is a far worse outcome than the brief pause recovery costs.