This is from a working group action - I tried AI and it couldn’t answer!
Hi @jkaye if I understand the question correctly (am no AI), then this is engine specific.
E.g. in QuickFIX/J one can configure the session to not persist any messages, reset sequence numbers on Logon or not even check seqnums at all.
All these options will lead to a disabled message recovery since seqnums are either
- reset anyway
- messages will be gap-filled since they were not persisted or
- there just can’t be any message recovery because seqnums are not checked and hence there will be no ResendRequests sent to the counterparty.
Did I understand the question correctly?
Cheers
Chris.
The FIX Protocol has two different methods for the recovery of messages. It can happen on the session or on the application layer.
The FIX Session Layer offers different session profiles, one of which is called Lightweight FIXT (a.k.a. LFIXT). The Lightweight FIXT session profile (LFIXT) is a restriction of the FIXT session profile. LFIXT eliminates the use of session layer retransmission of messages to simplify the session layer protocol. It is agreed out-of-band between the counterparties.
Application level recovery is supported with the ApplicationMessageRequest(35=BW) message**.** See the FIX specification for a description of the Application Sequencing concept. When using application level recovery, the session layer can respond to resend requests with so-called Gap-Fill messages. See Extension Pack 124 for a discussion of alternatives. The EP added ApplLevelRecoveryIndicator(1744) to the SequenceReset(35=4) message of the FIX Session Layer.
Agreed it’s engine specific. There’s also two sides to the question: 1) configure ourselves so we never resend messages (in quickfix, PersistMessages=N, or throw DoNotSend if PossDupFlag=Y), or 2) never issue a resend request from our side. The former has good use cases (not resending stale orders, not resending stale market data). Regarding the latter, it is not really a thing in quickfix (can’t speak for other engines). You could certainly reset on logon and disregard recovery at that point, but once you are in-Session, it seems ill-advised to disregard seqnums. Use case is relevant, e.g. if the other side will in fact resend stale market data and you don’t want that, you’d have to mitigate it another way.