Imported from previous forum
[ original email was from Nikhil Bose - assistsoft@yahoo.com ]
Hello,
Could someone offer some tips on how to decide between a Sequence Reset - Gapfill versus a Sequence Reset - Reset. Some counterparties seem to be more comfortable with Gapfill rather than Reset. But Reset seems to be easier (looser in the sense that the sequence number of the message itself is ignored). Also looks like Gapfill was not available till FIX 4.0, which led me to believe that older engines would prefer Reset. But that doesn’t seem to be the case.
Any guidelines, rules of thumb, etc. would be greatly appreciated.
Thanks,
Nikhil
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Could someone offer some tips on how to decide between a Sequence Reset - Gapfill versus a Sequence Reset - Reset. Some counterparties seem to be more comfortable with Gapfill rather than Reset. But Reset seems to be easier (looser in the sense that the sequence number of the message itself is ignored). Also looks like Gapfill was not available till FIX 4.0, which led me to believe that older engines would prefer Reset. But that doesn’t seem to be the case.
You are right that Gap Fill wasn’t around before 4.0. So if you have the misfortune of communicating with a 3.0 engine, you have no choice in this matter.
Seq Reset - Gap Fill is a much better way of handling problems than a Seq Reset - Reset. The reason is that a Gap Fill explicitly states exactly what messages should be skipped over. It is possible with a Seq Reset - Reset that one may lose messages.
For instance, assume a link that randomly drops messages. You are expecting 10. I send you 10 Execution Report, 11 Heartbeat, and 12 Execution Report. 10 and 11 are dropped. You get 12 and send a Resend Request of 10-999999. I send 10 Poss Dupe Execution Report, 11 Poss Dupe Seq Reset - Reset to 12, and 12 Poss Dupe Execution Report. The line is lossy, and 10 gets dropped again but 11 goes through. Because Seq Reset - Reset is processed without respect to sequence number, you are required to accept it, increment your next inbound sequence number to 12, and you may likely never know you missed 10 until the next morning when the trades don’t compare.
Now lets say when responding to your Resend Request I send 11 Poss Dupe Seq Reset - Gap Fill to 12, and 10 is dropped as before. Gap Fills are required to be processed in sequence, so your receiving 11 will trigger you to send another Resend Request from 10-999999, and eventually message 10 will be recovered.
In all FIX 4.0 and later implementations I’ve developed, I employ the rule of thumb that when responding to a Resend Request, I will ALWAYS use Seq Reset - Gap Fill and NEVER Seq Reset - Reset. I believe the only good use of Seq Reset - Reset is when a session becomes out of control and an operator needs to trigger it manually in an attempt to recover. In this case, the two parties can compare logs and see if anything important was missed.
Ryan’s example and recommendation of avoiding the use of Sequence Reset - Reset in favor of Sequence Reset - Gap Fill are consistent with the experience many others have had and the recommendation of the FIX Technical Committee.
> > Could someone offer some tips on how to decide between a Sequence Reset - Gapfill versus a Sequence Reset - Reset. Some counterparties seem to be more comfortable with Gapfill rather than Reset. But Reset seems to be easier (looser in the sense that the sequence number of the message itself is ignored). Also looks like Gapfill was not available till FIX 4.0, which led me to believe that older engines would prefer Reset. But that doesn’t seem to be the case.
>
> You are right that Gap Fill wasn’t around before 4.0. So if you have the misfortune of communicating with a 3.0 engine, you have no choice in this matter.
>
> Seq Reset - Gap Fill is a much better way of handling problems than a Seq Reset - Reset. The reason is that a Gap Fill explicitly states exactly what messages should be skipped over. It is possible with a Seq Reset - Reset that one may lose messages.
>
> For instance, assume a link that randomly drops messages. You are expecting 10. I send you 10 Execution Report, 11 Heartbeat, and 12 Execution Report. 10 and 11 are dropped. You get 12 and send a Resend Request of 10-999999. I send 10 Poss Dupe Execution Report, 11 Poss Dupe Seq Reset - Reset to 12, and 12 Poss Dupe Execution Report. The line is lossy, and 10 gets dropped again but 11 goes through. Because Seq Reset - Reset is processed without respect to sequence number, you are required to accept it, increment your next inbound sequence number to 12, and you may likely never know you missed 10 until the next morning when the trades don’t compare.
>
> Now lets say when responding to your Resend Request I send 11 Poss Dupe Seq Reset - Gap Fill to 12, and 10 is dropped as before. Gap Fills are required to be processed in sequence, so your receiving 11 will trigger you to send another Resend Request from 10-999999, and eventually message 10 will be recovered.
>
> In all FIX 4.0 and later implementations I’ve developed, I employ the rule of thumb that when responding to a Resend Request, I will ALWAYS use Seq Reset - Gap Fill and NEVER Seq Reset - Reset. I believe the only good use of Seq Reset - Reset is when a session becomes out of control and an operator needs to trigger it manually in an attempt to recover. In this case, the two parties can compare logs and see if anything important was missed.
>
>