Imported from previous forum
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
Duilio Gamba’s question concerning Poss Dupe and SeqReset-Resets brought to light what looks like a contradiction concerning Poss Dupe and SeqReset-Gap Fills.
I interpret “all messages created as the result of a resend request will contain the PossDupFlag set to ‘Y’” as meaning that a SeqReset-Gap Fill must be flagged as Poss Dup. Otherwise, the following error could result. You send:
10 - normal message
11 - admin
12 - admin
13 - normal message
14 - normal message
The other party misses 11 and 12, sees 13, and sends a Resend Request of 11-999999. Before you’ve gotten their Resend Request, you send message 14. The other party sees 14, and sends another Resend Request of 11-999999. Then you get both of their resend requests.
You send:
11 SeqReset-Gap Fill -> 13
13 Poss Dup normal message
14 Poss Dup normal message
in response to the first Resend Request. The other party receives these messages, processes them, and is expecting message 15. Then you process the second Resesd Request and send the same thing again:
11 SeqReset-Gap Fill -> 13
13 Poss Dup normal message
14 Poss Dup normal message
If you have not set Poss Dup on the SeqReset, the other party, expecting 15 and seeing 11, is required to drop the connection. Now if the SeqReset-Gap Fill was a Poss Dup, the other party, expecting 15, would ignore 11, 13 and 14 and everything would be happy. Hence I believe it is critical that all SeqReset-Gap Fill messages must be Poss Dup.
The Message Recovery section (p. 9) of the specification states that a FIX application must drop all Poss Dupe admins, which seems like a contradiction.
If people agree that Poss Dupe SeqReset-Gap Fills are the desired behavior, I suggest the following clarifications to the spec:
Under the Sequence Reset section (pp. 16-17), make it clear that all SeqReset - Gap Fills must be flagged Poss Dup.
Under the Message Recovery section (p. 9), add an exception that the only Admin message that should ever be sent Poss Dup is a SeqReset-Gap Fill. Also, on p. 8, mention in item 2. that the SeqReset-Gap Fill must be Poss Dupe, just like in item 1.
Comments?
Ryan Pierce
Townsend Analytics Ltd.
I’ve read Duilio Gamba’s and Ryan Pierce’s postings (some are posted in the General Q/A section) re: PossDupFlag and the SeqReset-Reset and SeqReset-GapFill messages.
Page 9 states “inadvertently retransmitted administrative messages”. I read that to mean any admin messages which are not supposed to be resent as a result of a ResendRequest (or messages already received). The paragraph above lists “certain administrative messages” which should not be resent and that SeqReset-GapFill can be used in response to a ResendRequest. I don’t think this should be interpreted as dropping or ignoring ALL resent admin messages. The list of messages which should not be resent lists “SeqReset”, however, I think the intention was to avoid resending the same SeqReset message. The idea is that SeqReset (in either form) is more of a course of action vs. a specific message stemming from receiving a ResendRequest. I think we should replace “SeqReset” with “previously sent SeqReset messages” in the list of those which should not be resent. This would leave SeqReset-GapFill, SeqReset-Reset, and Reject as the only admin messages which should be resent and this should be explicitly stated in the spec.
The spec states that “all messages created as a result of a resend request will contain the PossDupFlag set to ‘Y’” which I believe is the correct behavior.
The spec also states that sequence number should be ignored (at least initially) for SeqReset-Reset, Logon, Reject, and Logout so if a SeqReset-Reset is sent with PossDupFlag=Y, it shouldn’t matter.
You are correct (maybe it bit you too 
) in that you have to be careful not to process a SeqReset message which attempts to lower the sequence number. I submitted the following suggested paragraph to the FIX 4.1 Draft a couple of weeks ago to be included in the "Message Recovery Section":
"It is possible to have multiple ResendRequests issued in a row (i.e. 5 to 10 followed by 5 to 11). If sequence number 8, 10, and 11 represent application messages while the 5-7 and 9 represent administrative messages, the result may appear as SeqReset-GapFill with next of 8, message 8, SeqReset-GapFill with next of 10, and message 10 followed by SeqReset-GapFill with next of 8, message 8, SeqReset-GapFill with next of 10, message 10, and message 11. One must be careful to ignore the duplicate SeqReset-GapFill which is attempting to lower the next expected sequence number."
Thoughts?
Scott Atwell
816-340-7053
scott_atwell@americancentury.com
American Century
[ original email was from Duilio Gamba - ]
Well, I tend to agree with Ryan Pierce in that if SeqReset-GapFill messages were required to have the PossDupFlag set to ‘Y’, then a sequence of GapFill messages such as 5 -10 followed by 5 - 11 would be handled correctly by the regular PossDup - SeqNumber checking part of any implementation.
By the way, if people, upon detecting a message gap, followed the second suggested course of action from the FIX specs:
"if the receiver misses the second of five messages sent, messages 3-5 can be ignored and a resend request generated for messages 2-5 OR MESSAGED 3-5 CAN BE SAVED AND ONLY MESSAGE 2 RESENT"
Then this problem would not occur, right ? But I guess since both methods are acceptable then this is a mute point.
Duilio Gamba,
Financial Systems Group, Inc.