Imported from previous forum
Is this an accurate depiction of a resend req/gap fill scenario?
server expects 5 but receives 10 from client
<–server sends 35=2 resend request, beginseqno 5, endseqno 10
–>client sends 35=4 reset request, gapfill flag Y, newseqnum=7 (seqno’s 5-7 were simply admin messages)
server now expects 7
–>client sends 34=7, order, possdup flag Y
–>client sends 34=8, order, possdup flag Y
–>client sends 34=9, order, possdup flag Y
–>client sends 34=10 order, possdup flag Y
server and client are now in sync
Since FIX.4.2 have recommended setting end sequence number to 0 (which means all messages after beginseqno )instead of 10 in order to minimize likelihood of a resend loop - where each subsequent message from the client (might be in flight messages) causing additional resends. We tried to update the explanation in the FIXT1.1 specification.
<–server sends 35=2 resend request, beginseqno 5, endseqno 0
In the following message 34=5 (wasn’t listed)
–>client sends 35=4 reset request, gapfill flag Y, newseqnum=7 (seqno’s 5-7 were simply admin messages)
Otherwise looks good. Technically “beginseqno 5, endseqno 10” complies with the standard, but the best practice is to not request a closed range of fields.
Is this an accurate depiction of a resend req/gap fill scenario?
server expects 5 but receives 10 from client
<–server sends 35=2 resend request, beginseqno 5, endseqno 10
–>client sends 35=4 reset request, gapfill flag Y, newseqnum=7 (seqno’s 5-7 were simply admin messages)
server now expects 7
–>client sends 34=7, order, possdup flag Y
–>client sends 34=8, order, possdup flag Y
–>client sends 34=9, order, possdup flag Y
–>client sends 34=10 order, possdup flag Y
server and client are now in sync
I have added a reference to this nice example, and Jim’s note on best practice to FIXwiki at http://fixwiki.org/fixwiki/ResendRequest
Since FIX.4.2 have recommended setting end sequence number to 0 (which means all messages after beginseqno )instead of 10 in order to minimize likelihood of a resend loop - where each subsequent message from the client (might be in flight messages) causing additional resends. We tried to update the explanation in the FIXT1.1 specification.
<–server sends 35=2 resend request, beginseqno 5, endseqno 0
In the following message 34=5 (wasn’t listed)
–>client sends 35=4 reset request, gapfill flag Y, newseqnum=7 (seqno’s 5-7 were simply admin messages)
Otherwise looks good. Technically “beginseqno 5, endseqno 10” complies with the standard, but the best practice is to not request a closed range of fields.
Is this an accurate depiction of a resend req/gap fill scenario?
server expects 5 but receives 10 from client
<–server sends 35=2 resend request, beginseqno 5, endseqno 10
–>client sends 35=4 reset request, gapfill flag Y, newseqnum=7 (seqno’s 5-7 were simply admin messages)
server now expects 7
–>client sends 34=7, order, possdup flag Y
–>client sends 34=8, order, possdup flag Y
–>client sends 34=9, order, possdup flag Y
–>client sends 34=10 order, possdup flag Y
server and client are now in sync
Thanks guys, understood. Just to clarify, when server sends resend request, and client responds with 35=4 reset request, gapfill flag Y, and newseqnum=7, is it incorrect for the client to also send possdup flag (43=Y)? Also, what would be the accurate seqnum of the actual reset request message?
ie.
<-server sends 35=2_34=2_7=1_16=0
->client sends 35=4_34=1_43=Y_36=3_123=Y
->client sends 35=D_34=3_43=Y
I have added a reference to this nice example, and Jim’s note on best practice to FIXwiki at http://fixwiki.org/fixwiki/ResendRequest
Since FIX.4.2 have recommended setting end sequence number to 0 (which means all messages after beginseqno )instead of 10 in order to minimize likelihood of a resend loop - where each subsequent message from the client (might be in flight messages) causing additional resends. We tried to update the explanation in the FIXT1.1 specification.
<–server sends 35=2 resend request, beginseqno 5, endseqno 0
In the following message 34=5 (wasn’t listed)
–>client sends 35=4 reset request, gapfill flag Y, newseqnum=7 (seqno’s 5-7 were simply admin messages)
Otherwise looks good. Technically “beginseqno 5, endseqno 10” complies with the standard, but the best practice is to not request a closed range of fields.
Is this an accurate depiction of a resend req/gap fill scenario?
server expects 5 but receives 10 from client
<–server sends 35=2 resend request, beginseqno 5, endseqno 10
–>client sends 35=4 reset request, gapfill flag Y, newseqnum=7 (seqno’s 5-7 were simply admin messages)
server now expects 7
–>client sends 34=7, order, possdup flag Y
–>client sends 34=8, order, possdup flag Y
–>client sends 34=9, order, possdup flag Y
–>client sends 34=10 order, possdup flag Y
server and client are now in sync