Imported from previous forum
I’m implementing a FIX engine and have a question regarding sequence processing:
If an out-of-sequence condition occurs and the engine is waiting for an in-sequence message with the PossDup flag set, or a seqreset-reset message, suppose that a seqreset-reset message is received which is IN SEQUENCE. What should be the correct action for the engine to take? Should it discard this seqreset-reset message since it is in sequence, or process it as a correct seqreset-reset message and reset the sequence number? Whether this situation will ever occur is up to the implementation of the client.
Thanks in advance,
Peter Sen
Consultant, Australia
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> If an out-of-sequence condition occurs and the engine is waiting for an in-sequence message with the PossDup flag set, or a seqreset-reset message, suppose that a seqreset-reset message is received which is IN SEQUENCE. What should be the correct action for the engine to take? Should it discard this seqreset-reset message since it is in sequence, or process it as a correct seqreset-reset message and reset the sequence number? Whether this situation will ever occur is up to the implementation of the client.
You must process the message and set your next expected sequence number forward to the NewSeqNo. (Assuming, of course, NewSeqNo is greater than what is expected; trying to decrease the sequence number is an error.)
For instance, if you get:
10 Heartbeat
11 Heartbeat
15 Heartbeat (to which you send a Resend Request)
12 SeqReset-Reset to 18
You must then expect message 18. If you don’t, and keep expecting 12, the other side will send 18, forcing you to send a Resend Request, to which the other side will probably respond with 12 SeqReset-Reset to 19, and you’ll be in an infinite loop. (Note that it is far better in these cases to send SeqReset-GapFills but not, as far as I can tell, required.)
A SeqReset-Reset must be processed if its sequence number is >= expected. This is regardless of its PossDupe status. A SeqReset-GapFill must be processed only if its sequence number is equal to what is expected.
If a SeqReset-Reset or GapFill has a sequence number less than expected, some uncertainty exists. My take on the spec is that if it is PossDupe, it should always be ignored, and if it is not PossDupe, it is an error and the session needs to be dropped with an appropriate Logout message stating the error (re: FIX 4.1, underlined text on p. 9.) In FIX 4.1 it is clarified on page 8 that SeqResets in response to Resend Requests must be PossDupe. For PossDupe (and in some cases non-PossDupe) SeqResets with sequence numbers less than expected, some people have implemented logic that process the message anyway if NewSeqNo is > what is expected; I don’t see justification for doing so in the spec, although this is more of a gray issue.