Imported from previous forum
In case of gapfills in a partial range (NOT to infinity), the spec has examples where the end of the gap fill range are appplication messages. But what should be the new sequence number if the end of range are admin and I need to send a Seq-Reset-Gapfill. This impacts my gap-fill strategy of saving msgs ahead of seq and processing when the gap is filled.
e.g.
Receive 3, 4, 8, 9 , 10, 11 (I save 8-11)
SendResend 5-7 (6 and 7 happen to be admin msgs)
Receive 5
Receive 6, a Seq-Reset-Gap with NewSeqNo = ?
SHould he send New Seq No of 8 or 12.??
if New Seq = 12, It’s open to interpretation that 6 to 11 are admin- may not be true here,as I am going to process the queued msgs from 8(Another scenario this fails - I might have another gap and pending Resend request in the 8-11)
But if NewSeq is 8 the partner has ther choice of next sending from 8+(in which case the ‘partial’ gap fill request was redundant and partner behaves like he was requested resend 5 - infinity) OR restarting from the actual of 12(since that’s where we both agree is the next expected from him) inspite of the next expected NewSeqNo being 8 on the Gapfill msg??
Please Interpret
Thank You.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> In case of gapfills in a partial range (NOT to infinity), the spec has examples where the end of the gap fill range are appplication messages. But what should be the new sequence number if the end of range are admin and I need to send a Seq-Reset-Gapfill. This impacts my gap-fill strategy of saving msgs ahead of seq and processing when the gap is filled.
It can cause problems if someone volunteers more info than asked for when responding to a resend request.
> e.g.
>
> Receive 3, 4, 8, 9 , 10, 11 (I save 8-11)
> SendResend 5-7 (6 and 7 happen to be admin msgs)
> Receive 5
> Receive 6, a Seq-Reset-Gap with NewSeqNo = ?
> SHould he send New Seq No of 8 or 12.??
If you send a ResendRequest for 5-7, and they’re business messages, you’ll likely see:
5 PD Message
6 PD Message
7 PD Message
and then you are expecting 8.
If 6 and 7 are admins, they should send:
5 PD Message
6 PD Gap Fill to 8
Note that in both these cases, you’re expecting 8 after the gap has been filled. It doesn’t matter if they are business or admin messages.
Also note that the other party’s next message to you will be 12. So you should now process messages 8-11 that you have stored immediately following being gap filled to 8, and when the other party sends 12, you are ready.
> if New Seq = 12, It’s open to interpretation that 6 to 11 are admin- may not be true here,as I am going to process the queued msgs from 8(Another scenario this fails - I might have another gap and pending Resend request in the 8-11)
The partner shouldn’t do that. You specifically asked for 5-7, so they should give you 5-7 (or gap fill you to 8) ONLY. Otherwise, things are very confusing. You’re already storing 8-11, and are entitled to process them once the gap is filled. If they gap fill you to 12, then you’ve got a serious contradiction; they think they’ve instructed you to ignore any business content in those messages (i.e. in the case of a stale order), but you may already have processed them.
> But if NewSeq is 8 the partner has ther choice of next sending from 8+(in which case the ‘partial’ gap fill request was redundant and partner behaves like he was requested resend 5 - infinity) OR restarting from the actual of 12(since that’s where we both agree is the next expected from him) inspite of the next expected NewSeqNo being 8 on the Gapfill msg??
No, the partner CANNOT start sending from 8+ (unless you’ve send him another Resend Request for 8-something). The partner has already committed messages 8-11. 12 is next.
NewSeqNo on a gap fill really isn’t the next message to be sent. It falls under 3 categories:
Req 5-7 - In this case, it is the next message following the gap, 8 in this case, which ISN’T NECESSARILY the next message the other side will transmit.
Req 5-20 - In this case, it is the next message one would normally send, which is 12, as the end of the range is higher than the highest sequence number. But I don’t see why anyone would ever send this; it implies you’ve seen a message 21 that they never sent.
Req 5-Infinity (where Infinity is defined differently for 4.0-4.1 and 4.2-4.3) - In this case, it is the next message one would normally send, which is 12.
I believe either FIX 4.3 or FIX 4.2 errata clarified the meaning of this.
The later spec version(s) recommend that one use the X-Infinity form of recovery, although the finite range method is still perfectly compliant. Doing so is much simpler. Why hang on to 8-11 and deal with the complexities resulting from this, when you can drop them all, ask for 5-Infinity, and start processing based on what is sent back?
It also allows for faster reconvergence. If the other side is sending messages rapidly, getting multiple out-of-sequence messages causes much more Resend Request thrashing if asking for specific ranges than simply asking for 5-Infinity.
Thank You very much.
>The later spec version(s) recommend that one use >the X-Infinity form of recovery, although the >finite range method is still perfectly >compliant. Doing so is much simpler. Why hang on >to 8-11 and deal with the complexities resulting >from this, when you can drop them all, ask for 5->Infinity, and start processing based on what is >sent back?
>It also allows for faster reconvergence. If the >other side is sending messages rapidly, getting >multiple out-of-sequence messages causes much >more Resend Request thrashing if asking for >specific ranges than simply asking for 5->Infinity.
If loosing messages in the network is the root cause, than x-infinity strategy could cause thrashing also, though concievably less.
Perhaps if the unprocessed saved queue is long in relation to the missing records I need resent, I could possibly,(depending on partner’s implementation) be faster just getting the missing gap. Also I might want to process some ‘early’ application messages before the gap is filled, breaking the spec internally, but pipelining the messages, and don’t want to deal with overhead of processing unnecessary posdups.