Imported from previous forum
Hi everyone,
I am new here. I just read the FIX4.1(19990603) spec last week. I find the spec while containing a lots of information, is very difficult to understand at certain points. Probably because many people are writing different portion of it. Over all, I find the handling of the sequence reset message to be most confusing. Following are points which I think is true regarding the sequence reset message, along with some questions. Please let me know if otherwise.
I am speaking from a Vendor point of view, and I am not contributing any data to the server(thank goodness).
-
The Sequence Reset message is often being spoken of as if they are two different messages. If the GapFill field is “Y”, then it’s a SeqReset-GapFill message, otherwise it’s a SeqReset-Reset message.
-
When a sequence reset message comes in, here are the possible scenarios:
GapFill=Y ==> MsgSeqNum valid.
- MsgSeqNum > next_seqNo ==> discard message, issue resent.
- ((MsgSeqNum < next_seqNo) && (PossDupFlag=Y)) ==> Discard message.
- ((MsgSeqNum < next_seqNo) && (PossDupFlag=N)) ==> Logout with reason.
- ((MsgSeqNo == next_seqNo) && (NewSeqNo < next_seqNo)) ==> Discard message.
- ((MsgSeqNo == next_seqNo) && (NewSeqNo > next_seqNo)) ==> Set next_seqNo to NewSeqNo.
GapFill=N ==> Ignore MsgSeqNum.
6. ((PossDupFlag=N) && (NewSeqNo < next_seqNo)) ==> Discard message.
7. ((PossDupFlag=N) && (NewSeqNo > next_seqNo)) ==> Set next_seqNo to NewSeqNo.
8. ((PossDupFlag=Y) && (NewSeqNo < next_seqNo)) ==> Discard message.
9. ((PossDupFlag=Y) && (NewSeqNo > next_seqNo)) ==> ???
next_seqNo is the sequence number expecting for the next message.
My question is what to do in case 9 above?
Also, as I understand, case 3, 6 and 7 should never happen since sequence reset messages should only be send with a resent request, in which case, the PossDupFlag should always be Y.
Comments?
Thanks in advance.
Wade.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> I am new here. I just read the FIX4.1(19990603) spec last week. I find the spec while containing a lots of information, is very difficult to understand at certain points. Probably because many people are writing different portion of it. Over all, I find the handling of the sequence reset message to be most confusing. Following are points which I think is true regarding the sequence reset message, along with some questions. Please let me know if otherwise.
The core problem here is that the spec has conflicting statements relating to Sequence Reset messages:
"NOTE: In ALL cases, the FIX session should be terminated if the incoming sequence number is less than expected and the PossDupFlag is not set. A Logout message with some descriptive text should be sent to the other side before closing the session." - FIX 4.1 with errata, p. 11
"SeqReset-Reset Ignore the incoming sequence number. The NewSeqNo field of the SeqReset message will contain the sequence number of the next message to be transmitted." - FIX 4.1 with errata, p. 12
"If the GapFill field is not present (or set to N), it can be assumed that the purpose of the sequence reset message is to recover from an out-of-sequence condition. The MsgSeqNum in the header should be ignored (i.e. the receipt of a sequence reset message with an out of sequence MsgSeqNum should not generate resend requests)." - FIX 4.1 with errata, p. 19
It is my belief that, since the first of these three conditions states "all" and is underlined, bolded, and has asterisks around the "all" that it takes priority.
Regardless, a clarification needs to be made in FIX 4.2.
> - The Sequence Reset message is often being spoken of as if they are two different messages. If the GapFill field is “Y”, then it’s a SeqReset-GapFill message, otherwise it’s a SeqReset-Reset message.
As an abbreviation, people speak of "SeqReset-Reset" and "SeqReset-Gap Fill" for Sequence Reset messages with GapFillFlag not specified or containing "N", or containing "Y", respectively.
Let’s ignore NewSeqNo for a second and look at out of sequence conditions for MsgSeqNum of a SeqReset message
SeqReset-Reset
MsgSeqNum < expected, not Poss Dupe: Send logout and disconnect
MsgSeqNum < expected, Poss Dupe: Ignore
MsgSeqNum > expected, not Poss Dupe: Process anyway, DON’T send Resend Request
MsgSeqNum > expected, Poss Dupe: Process anyway, DON’T send Resend Request
Seq Reset-Gap Fill
MsgSeqNum < expected, not Poss Dupe: Send logout and disconnect
MsgSeqNum < expected, Poss Dupe: Ignore
MsgSeqNum > expected, not Poss Dupe: Don’t process, send Resend Request
MsgSeqNum > expected, Poss Dupe: Don’t process, send Resend Request
Assume a SeqReset message passes these tests and should be processed. If the NewSeqNo field is decreasing the FIX engine’s next expected sequence number, that action should not be done, and a Reject should be sent.
Further, I’d like to state that the best way of handling gaps, assuming the problem is a lost message or broken connection, is to use SeqReset - Gap Fills. This assures that you are skipping over only the messages that the FIX engine intends to be skipped over. Responding with a SeqReset - Reset message, while still remaining compliant, is like taking a sledge hammer to the problem; it gets the job done, but can inflict collateral damage. It is best used in severe cases such as when you’ve lost your database, or when initiated manually by an operator.
In addition, it is required in FIX 4.1 that all SeqReset messages in response to a Resend Request are Poss Dupe. While 4.1 makes the matter explicit, it is my belief that it is required in FIX 4.0 as well:
"All messages created as the result of a resend request will contain the PossDupFlag field set to "Y"…" - FIX 4.0 p. 5
I maintain that SeqReset messages created as the result of a Resend Request thus must be Poss Dupe.
One particularly problematic approach I’ve seen is to send a SeqReset-Reset that is not Poss Dupe with a MsgSeqNum=0 and, say, a NewSeqNo=100. It is my belief that this should not be done, and the other party should send a Logout and break the session. It wouldn’t be that much harder, and would be perfectly compliant, to send PossDupFlag=Y, MsgSeqNum=99, NewSeqNo=100 in such a case. (Or better, send a SeqReset-Gap Fill explicitly for the messages missed.)
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
[lengthy discussion deleted]
In short, there’s a controversy over whether a Seq Reset - Reset with a sequence number less than expected and not poss dupe should be processed, or whether it should cause the session to terminate.
The core problem was that two confliciting, absolute statements were in the spec; 1. that the sequence number of a Seq Reset - Reset should be ignored, and 2. that all non-poss dupe messages with sequence numbers less than expected should cause a logout to be sent and the session broken.
A decision was made in FIX 4.2 that the statement that the sequence number for a Seq Reset - Reset should be ignored takes priority.
In other words, in FIX 4.2 if you are expecting 100 and receive 1 Seq Reset - Reset to 200, you must honor the request, and must not log the person off for using sequence number 1 again.
Note that Poss Dupe Seq Reset - Gap Fill is by far the preferred method for handling out of sequence conditions, as Seq Reset - Reset presents the significant possibility of message loss.