Heavy Market Data Consumers and MsgSeqNum limitations

Imported from previous forum

Has anyone run into a problem with MsgSeqNum running out of room? The max size is 32 bit integer, signed… a little over 2 billion. While this is a big number if a client was subscribed to a large market data feed couldn’t they easily exhaust the available MsgSeqNum range in a single trading session?

Has anyone run into a problem with MsgSeqNum running out of room? The max size is 32 bit integer, signed… a little over 2 billion. While this is a big number if a client was subscribed to a large market data feed couldn’t they easily exhaust the available MsgSeqNum range in a single trading session?

MsgSeqNum is not defined as a 32 bit signed integer by the FIX Protocol. It is represented in FIX as a base type of “int” but that implies no maximum value whatsoever.

An implied limit of less than 1 million messages per session existed in FIX 4.0 and quite possibly 4.1 due to the use of EndSeqNo(16)=999999 to request all messages after a certain point in a Resend Request. The field could certainly accomodate higher sequence numbers, but recovery wouldn’t work. This was remedied by FIX 4.2.

FIX engines may consider MsgSeqNum a 32 big signed integer, but that’s not a part of the FIX protocol itself.

Large market data feeds are rarely provided through standard FIX engines and FIX sessions but rather via multicast. Ryan already explained that there is no limitation and I would add not to offer the ability to re-request an arbitrary amount of market data messages in the first place. It makes sense to use Application Sequencing where you assign ApplID values to those messages that should be re-requestable (over TCP/IP), e.g. trades.
MsgSeqNum in market data messages can be useful to crosslink between snapshots and incrementals when they are not sent over the same channel (out-of-band). Snapshots can then reference the last MsgSeqNum of an incremental update that has been processed for the snapshot.

Has anyone run into a problem with MsgSeqNum running out of room? The max size is 32 bit integer, signed… a little over 2 billion. While this is a big number if a client was subscribed to a large market data feed couldn’t they easily exhaust the available MsgSeqNum range in a single trading session?