# SeqNum Gap Fill

**URL:** <https://forum.fixtrading.org/t/seqnum-gap-fill/12665>\
**Category:** General Q&A\
**Tags:** imported, fix-technology, xid\_169911\
**Created:** [April 13, 2012, 2:40am UTC](https://forum.fixtrading.org/t/seqnum-gap-fill/12665 "2012-04-13T02:40:36Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![chrisstuart24\_x](https://avatars.discourse-cdn.com/v4/letter/c/e480ec/32.png) [@chrisstuart24\_x](https://forum.fixtrading.org/u/chrisstuart24_x)\
**Post date:** [April 13, 2012, 2:40am UTC](https://forum.fixtrading.org/t/seqnum-gap-fill/12665/1 "2012-04-13T02:40:36Z")

</div>

Imported from previous forum

---

<div class="post-metadata">

**Author:** ![chrisstuart24\_x](https://avatars.discourse-cdn.com/v4/letter/c/e480ec/32.png) [@chrisstuart24\_x](https://forum.fixtrading.org/u/chrisstuart24_x)\
**Post date:** [April 13, 2012, 2:40am UTC](https://forum.fixtrading.org/t/seqnum-gap-fill/12665/2 "2012-04-13T02:40:36Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jim.northey](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/jim.northey/32/37_2.png) [@jim.northey](https://forum.fixtrading.org/u/jim.northey)\
**Post date:** [April 13, 2012, 3:07am UTC](https://forum.fixtrading.org/t/seqnum-gap-fill/12665/3 "2012-04-13T03:07:37Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![johncameron](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/johncameron/32/56_2.png) [@johncameron](https://forum.fixtrading.org/u/johncameron)\
**Post date:** [April 13, 2012, 4:16am UTC](https://forum.fixtrading.org/t/seqnum-gap-fill/12665/4 "2012-04-13T04:16:50Z")

</div>

I have added a reference to this nice example, and Jim’s note on best practice to FIXwiki at [http://fixwiki.org/fixwiki/ResendRequest](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

---

<div class="post-metadata">

**Author:** ![chrisstuart24\_x](https://avatars.discourse-cdn.com/v4/letter/c/e480ec/32.png) [@chrisstuart24\_x](https://forum.fixtrading.org/u/chrisstuart24_x)\
**Post date:** [April 13, 2012, 7:04pm UTC](https://forum.fixtrading.org/t/seqnum-gap-fill/12665/5 "2012-04-13T19:04:16Z")

</div>

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](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