Imported from previous forum
Hi All,
we are having a discussion with our customer regarding the following Fix Standard 4.2 sequence of messages, can you help us in understanding if Exchange or Client is not correctly bahaving?
Client Login Request:
8=FIX.4.29=14835=A50=BNL00334=10049=042556=TLX43=N52=20030716-08:36
:41.00098=0108=8095=4996=1BNL003 BnL003
93=189=110=135
Exchange Login Response:
8=FIX.4.29=13235=A49=TLX56=042534=150=152=20030716-08:36:42.3
38369=098=0108=8095=3296=BNL003 0425
93=889=BK39835910=249
Exchange Resend Request message from message sequence number 1 (TAG 7) to 99 (TAG 99)
8=FIX.4.29=8235=249=TLX56=042534=250=152=20030716-08:36:42.35
47=116=9993=889=BK39835910=148
Client Sequence Reset message with TAG 36= 100:
8=FIX.4.29=12135=450=BNL00334=149=042556=TLX43=Y52=20030716-08:37:0
3.000122=20030716-08:37:03.00036=100123=Y93=889=BK39835910=143
New Message sent by the Client:
8=FIX.4.29=9435=c50=BNL00334=10149=042556=TLX52=20030716-08:37:03.00
0320=LIST321=393=889=BK39835910=177
New Resend Request from Exchange asking for Message Sequence Number 100:
8=FIX.4.29=8335=249=TLX56=042534=350=152=20030716-08:37:04.55
77=10016=093=889=BK39835910=184
-
Is correct the behaviour of the Exchange or the Exchange should not have requested the last Resend Request message (TAG 34 = 3)?
-
Is correct the behaviour of the Client or the Client should have sent a Sequence Reset Gap Fill message with TAG 36 = 101 instead of 100 (TAG 34 = 3)?
Thank you in advance
Stefano Ferrari
[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
Stefano,
Here’s a summary of your dialog:
Client: Login Seq=100
Exchng: Login Seq=1
Exchng: Resend Seq=1-99
Client: GapFill NewSeqNo=100
Client: EMail Seq=101
Exchng: Resend Seq=100-infinity
The Client responded correctly to ResendRequest with GapFill/NewSeqNo=100, one beyond what the Exchange asked for. The Exchange already has Seq=100 from the Client in hand - its Login message - and should have been expecting Seq=101 after processing the GapFill.
> Hi All,
>
> we are having a discussion with our customer regarding the following Fix Standard 4.2 sequence of messages, can you help us in understanding if Exchange or Client is not correctly bahaving?
>
> Client Login Request:
> 8=FIX.4.29=14835=A50=BNL00334=10049=042556=TLX43=N52=20030716-08:36
> :41.00098=0108=8095=4996=1BNL003 BnL003
> 93=189=110=135
>
> Exchange Login Response:
> 8=FIX.4.29=13235=A49=TLX56=042534=150=152=20030716-08:36:42.3
> 38369=098=0108=8095=3296=BNL003 0425
> 93=889=BK39835910=249
>
> Exchange Resend Request message from message sequence number 1 (TAG 7) to 99 (TAG 99)
> 8=FIX.4.29=8235=249=TLX56=042534=250=152=20030716-08:36:42.35
> 47=116=9993=889=BK39835910=148
>
> Client Sequence Reset message with TAG 36= 100:
> 8=FIX.4.29=12135=450=BNL00334=149=042556=TLX43=Y52=20030716-08:37:0
> 3.000122=20030716-08:37:03.00036=100123=Y93=889=BK39835910=143
>
> New Message sent by the Client:
> 8=FIX.4.29=9435=c50=BNL00334=10149=042556=TLX52=20030716-08:37:03.00
> 0320=LIST321=393=889=BK39835910=177
>
> New Resend Request from Exchange asking for Message Sequence Number 100:
> 8=FIX.4.29=8335=249=TLX56=042534=350=152=20030716-08:37:04.55
> 77=10016=093=889=BK39835910=184
>
> - Is correct the behaviour of the Exchange or the Exchange should not have requested the last Resend Request message (TAG 34 = 3)?
>
> - Is correct the behaviour of the Client or the Client should have sent a Sequence Reset Gap Fill message with TAG 36 = 101 instead of 100 (TAG 34 = 3)?
>
> Thank you in advance
>
> Stefano Ferrari
>
[ original email was from Olexiy Getmanchuk - alexeyg@in4reach.com ]
Hi All,
Quote from FIX 4.2 spec for MsgType=4(Sequence Reset (Gap Fill))
"
The message in all situations specifies
NewSeqNo to reset as the value of the next sequence number immediately following the messages and/or sequence numbers being skipped.
"
Therefore, EMail from client has to have SeqNum=100, not 101 and Exchange asked for missed 100 correctly.
WBR,
Olexiy.
> Stefano,
>
> Here’s a summary of your dialog:
> Client: Login Seq=100
> Exchng: Login Seq=1
> Exchng: Resend Seq=1-99
> Client: GapFill NewSeqNo=100
> Client: EMail Seq=101
> Exchng: Resend Seq=100-infinity
>
> The Client responded correctly to ResendRequest with GapFill/NewSeqNo=100, one beyond what the Exchange asked for. The Exchange already has Seq=100 from the Client in hand - its Login message - and should have been expecting Seq=101 after processing the GapFill.
>
> > Hi All,
> >
> > we are having a discussion with our customer regarding the following Fix Standard 4.2 sequence of messages, can you help us in understanding if Exchange or Client is not correctly bahaving?
> >
> > Client Login Request:
> > 8=FIX.4.29=14835=A50=BNL00334=10049=042556=TLX43=N52=20030716-08:36
> > :41.00098=0108=8095=4996=1BNL003 BnL003
> > 93=189=110=135
> >
> > Exchange Login Response:
> > 8=FIX.4.29=13235=A49=TLX56=042534=150=152=20030716-08:36:42.3
> > 38369=098=0108=8095=3296=BNL003 0425
> > 93=889=BK39835910=249
> >
> > Exchange Resend Request message from message sequence number 1 (TAG 7) to 99 (TAG 99)
> > 8=FIX.4.29=8235=249=TLX56=042534=250=152=20030716-08:36:42.35
> > 47=116=9993=889=BK39835910=148
> >
> > Client Sequence Reset message with TAG 36= 100:
> > 8=FIX.4.29=12135=450=BNL00334=149=042556=TLX43=Y52=20030716-08:37:0
> > 3.000122=20030716-08:37:03.00036=100123=Y93=889=BK39835910=143
> >
> > New Message sent by the Client:
> > 8=FIX.4.29=9435=c50=BNL00334=10149=042556=TLX52=20030716-08:37:03.00
> > 0320=LIST321=393=889=BK39835910=177
> >
> > New Resend Request from Exchange asking for Message Sequence Number 100:
> > 8=FIX.4.29=8335=249=TLX56=042534=350=152=20030716-08:37:04.55
> > 77=10016=093=889=BK39835910=184
> >
> > - Is correct the behaviour of the Exchange or the Exchange should not have requested the last Resend Request message (TAG 34 = 3)?
> >
> > - Is correct the behaviour of the Client or the Client should have sent a Sequence Reset Gap Fill message with TAG 36 = 101 instead of 100 (TAG 34 = 3)?
> >
> > Thank you in advance
> >
> > Stefano Ferrari
> >
>
[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
The GapFill is just that - filling the range of messages that the Exchange says it missed 1-99. Message 100 was consumed by Login, the Exchange processed it, and it would be illegal for the Client to reuse Seq=100 for another message. The Exchange should not have asked for another resend.
> Hi All,
>
> Quote from FIX 4.2 spec for MsgType=4(Sequence Reset (Gap Fill))
> "
> The message in all situations specifies
> NewSeqNo to reset as the value of the next sequence number immediately following the messages and/or sequence numbers being skipped.
> "
>
> Therefore, EMail from client has to have SeqNum=100, not 101 and Exchange asked for missed 100 correctly.
>
> WBR,
> Olexiy.
>
> > Stefano,
> >
> > Here’s a summary of your dialog:
> > Client: Login Seq=100
> > Exchng: Login Seq=1
> > Exchng: Resend Seq=1-99
> > Client: GapFill NewSeqNo=100
> > Client: EMail Seq=101
> > Exchng: Resend Seq=100-infinity
> >
> > The Client responded correctly to ResendRequest with GapFill/NewSeqNo=100, one beyond what the Exchange asked for. The Exchange already has Seq=100 from the Client in hand - its Login message - and should have been expecting Seq=101 after processing the GapFill.
> >
> > > Hi All,
> > >
> > > we are having a discussion with our customer regarding the following Fix Standard 4.2 sequence of messages, can you help us in understanding if Exchange or Client is not correctly bahaving?
> > >
> > > Client Login Request:
> > > 8=FIX.4.29=14835=A50=BNL00334=10049=042556=TLX43=N52=20030716-08:36
> > > :41.00098=0108=8095=4996=1BNL003 BnL003
> > > 93=189=110=135
> > >
> > > Exchange Login Response:
> > > 8=FIX.4.29=13235=A49=TLX56=042534=150=152=20030716-08:36:42.3
> > > 38369=098=0108=8095=3296=BNL003 0425
> > > 93=889=BK39835910=249
> > >
> > > Exchange Resend Request message from message sequence number 1 (TAG 7) to 99 (TAG 99)
> > > 8=FIX.4.29=8235=249=TLX56=042534=250=152=20030716-08:36:42.35
> > > 47=116=9993=889=BK39835910=148
> > >
> > > Client Sequence Reset message with TAG 36= 100:
> > > 8=FIX.4.29=12135=450=BNL00334=149=042556=TLX43=Y52=20030716-08:37:0
> > > 3.000122=20030716-08:37:03.00036=100123=Y93=889=BK39835910=143
> > >
> > > New Message sent by the Client:
> > > 8=FIX.4.29=9435=c50=BNL00334=10149=042556=TLX52=20030716-08:37:03.00
> > > 0320=LIST321=393=889=BK39835910=177
> > >
> > > New Resend Request from Exchange asking for Message Sequence Number 100:
> > > 8=FIX.4.29=8335=249=TLX56=042534=350=152=20030716-08:37:04.55
> > > 77=10016=093=889=BK39835910=184
> > >
> > > - Is correct the behaviour of the Exchange or the Exchange should not have requested the last Resend Request message (TAG 34 = 3)?
> > >
> > > - Is correct the behaviour of the Client or the Client should have sent a Sequence Reset Gap Fill message with TAG 36 = 101 instead of 100 (TAG 34 = 3)?
> > >
> > > Thank you in advance
> > >
> > > Stefano Ferrari
> > >
> >
>
[ original email was from Olexiy Getmanchuk - alexeyg@in4reach.com ]
Since you, Dean, are a member of Certifiaction group it’s hard to argue with you…
But’ll try =)
Let’s consider such scenario:
FIX Session is established correctly and everything is fine.
Client SeqNums (in/out): 1000:2000
Server SeqNums (in/out): 2000:1000
Then Server sends Resend Request 1-100.
Let’s suppose that client don’t want to send those messages, issue SeqReset-GapFill and after that TestRequest (as example).
In my opinion, next actions should be as following:
Client: SeqReset-GapFill (SeqNum=1, GapFillFlag=Y, NewSeqNo=2001)
Client: TestRequest (seqNum=2001)
Server: Heartbeat (seqNum=1001)
Am I wrong?
Thanks,
Olexiy.
> The GapFill is just that - filling the range of messages that the Exchange says it missed 1-99. Message 100 was consumed by Login, the Exchange processed it, and it would be illegal for the Client to reuse Seq=100 for another message. The Exchange should not have asked for another resend.
>
>
> > Hi All,
> >
> > Quote from FIX 4.2 spec for MsgType=4(Sequence Reset (Gap Fill))
> > "
> > The message in all situations specifies
> > NewSeqNo to reset as the value of the next sequence number immediately following the messages and/or sequence numbers being skipped.
> > "
> >
> > Therefore, EMail from client has to have SeqNum=100, not 101 and Exchange asked for missed 100 correctly.
> >
> > WBR,
> > Olexiy.
> >
> > > Stefano,
> > >
> > > Here’s a summary of your dialog:
> > > Client: Login Seq=100
> > > Exchng: Login Seq=1
> > > Exchng: Resend Seq=1-99
> > > Client: GapFill NewSeqNo=100
> > > Client: EMail Seq=101
> > > Exchng: Resend Seq=100-infinity
> > >
> > > The Client responded correctly to ResendRequest with GapFill/NewSeqNo=100, one beyond what the Exchange asked for. The Exchange already has Seq=100 from the Client in hand - its Login message - and should have been expecting Seq=101 after processing the GapFill.
> > >
> > > > Hi All,
> > > >
> > > > we are having a discussion with our customer regarding the following Fix Standard 4.2 sequence of messages, can you help us in understanding if Exchange or Client is not correctly bahaving?
> > > >
> > > > Client Login Request:
> > > > 8=FIX.4.29=14835=A50=BNL00334=10049=042556=TLX43=N52=20030716-08:36
> > > > :41.00098=0108=8095=4996=1BNL003 BnL003
> > > > 93=189=110=135
> > > >
> > > > Exchange Login Response:
> > > > 8=FIX.4.29=13235=A49=TLX56=042534=150=152=20030716-08:36:42.3
> > > > 38369=098=0108=8095=3296=BNL003 0425
> > > > 93=889=BK39835910=249
> > > >
> > > > Exchange Resend Request message from message sequence number 1 (TAG 7) to 99 (TAG 99)
> > > > 8=FIX.4.29=8235=249=TLX56=042534=250=152=20030716-08:36:42.35
> > > > 47=116=9993=889=BK39835910=148
> > > >
> > > > Client Sequence Reset message with TAG 36= 100:
> > > > 8=FIX.4.29=12135=450=BNL00334=149=042556=TLX43=Y52=20030716-08:37:0
> > > > 3.000122=20030716-08:37:03.00036=100123=Y93=889=BK39835910=143
> > > >
> > > > New Message sent by the Client:
> > > > 8=FIX.4.29=9435=c50=BNL00334=10149=042556=TLX52=20030716-08:37:03.00
> > > > 0320=LIST321=393=889=BK39835910=177
> > > >
> > > > New Resend Request from Exchange asking for Message Sequence Number 100:
> > > > 8=FIX.4.29=8335=249=TLX56=042534=350=152=20030716-08:37:04.55
> > > > 77=10016=093=889=BK39835910=184
> > > >
> > > > - Is correct the behaviour of the Exchange or the Exchange should not have requested the last Resend Request message (TAG 34 = 3)?
> > > >
> > > > - Is correct the behaviour of the Client or the Client should have sent a Sequence Reset Gap Fill message with TAG 36 = 101 instead of 100 (TAG 34 = 3)?
> > > >
> > > > Thank you in advance
> > > >
> > > > Stefano Ferrari
> > > >
> > >
> >
>
[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
Olexiy,
I can be very wrong sometimes and no one hesitates to disagree with me…
In a SequenceReset/GapFill=Y NewSeqNo is logically limited to the range noted in the ResendRequest it answers plus 1. NewSeqNo must be “the value of the next sequence number immediately following the … sequence numbers being skipped.” For your intrepretation to be correct the description would have to be “the value of the next sequence number to be expected by the receiver.” But that’s the definition when GapFill=N.
In your example the GapFill is not skipping messages 1-2000, only 1-100, so NewSeqNo should be 101.
> Since you, Dean, are a member of Certifiaction group it’s hard to argue with you…
>
> But’ll try =)
> Let’s consider such scenario:
> FIX Session is established correctly and everything is fine.
>
> Client SeqNums (in/out): 1000:2000
> Server SeqNums (in/out): 2000:1000
>
> Then Server sends Resend Request 1-100.
>
> Let’s suppose that client don’t want to send those messages, issue SeqReset-GapFill and after that TestRequest (as example).
>
> In my opinion, next actions should be as following:
>
> Client: SeqReset-GapFill (SeqNum=1, GapFillFlag=Y, NewSeqNo=2001)
> Client: TestRequest (seqNum=2001)
> Server: Heartbeat (seqNum=1001)
>
> Am I wrong?
>
> Thanks,
> Olexiy.
>
> > The GapFill is just that - filling the range of messages that the Exchange says it missed 1-99. Message 100 was consumed by Login, the Exchange processed it, and it would be illegal for the Client to reuse Seq=100 for another message. The Exchange should not have asked for another resend.
> >
> >
> > > Hi All,
> > >
> > > Quote from FIX 4.2 spec for MsgType=4(Sequence Reset (Gap Fill))
> > > "
> > > The message in all situations specifies
> > > NewSeqNo to reset as the value of the next sequence number immediately following the messages and/or sequence numbers being skipped.
> > > "
> > >
> > > Therefore, EMail from client has to have SeqNum=100, not 101 and Exchange asked for missed 100 correctly.
> > >
> > > WBR,
> > > Olexiy.
> > >
> > > > Stefano,
> > > >
> > > > Here’s a summary of your dialog:
> > > > Client: Login Seq=100
> > > > Exchng: Login Seq=1
> > > > Exchng: Resend Seq=1-99
> > > > Client: GapFill NewSeqNo=100
> > > > Client: EMail Seq=101
> > > > Exchng: Resend Seq=100-infinity
> > > >
> > > > The Client responded correctly to ResendRequest with GapFill/NewSeqNo=100, one beyond what the Exchange asked for. The Exchange already has Seq=100 from the Client in hand - its Login message - and should have been expecting Seq=101 after processing the GapFill.
> > > >
> > > > > Hi All,
> > > > >
> > > > > we are having a discussion with our customer regarding the following Fix Standard 4.2 sequence of messages, can you help us in understanding if Exchange or Client is not correctly bahaving?
> > > > >
> > > > > Client Login Request:
> > > > > 8=FIX.4.29=14835=A50=BNL00334=10049=042556=TLX43=N52=20030716-08:36
> > > > > :41.00098=0108=8095=4996=1BNL003 BnL003
> > > > > 93=189=110=135
> > > > >
> > > > > Exchange Login Response:
> > > > > 8=FIX.4.29=13235=A49=TLX56=042534=150=152=20030716-08:36:42.3
> > > > > 38369=098=0108=8095=3296=BNL003 0425
> > > > > 93=889=BK39835910=249
> > > > >
> > > > > Exchange Resend Request message from message sequence number 1 (TAG 7) to 99 (TAG 99)
> > > > > 8=FIX.4.29=8235=249=TLX56=042534=250=152=20030716-08:36:42.35
> > > > > 47=116=9993=889=BK39835910=148
> > > > >
> > > > > Client Sequence Reset message with TAG 36= 100:
> > > > > 8=FIX.4.29=12135=450=BNL00334=149=042556=TLX43=Y52=20030716-08:37:0
> > > > > 3.000122=20030716-08:37:03.00036=100123=Y93=889=BK39835910=143
> > > > >
> > > > > New Message sent by the Client:
> > > > > 8=FIX.4.29=9435=c50=BNL00334=10149=042556=TLX52=20030716-08:37:03.00
> > > > > 0320=LIST321=393=889=BK39835910=177
> > > > >
> > > > > New Resend Request from Exchange asking for Message Sequence Number 100:
> > > > > 8=FIX.4.29=8335=249=TLX56=042534=350=152=20030716-08:37:04.55
> > > > > 77=10016=093=889=BK39835910=184
> > > > >
> > > > > - Is correct the behaviour of the Exchange or the Exchange should not have requested the last Resend Request message (TAG 34 = 3)?
> > > > >
> > > > > - Is correct the behaviour of the Client or the Client should have sent a Sequence Reset Gap Fill message with TAG 36 = 101 instead of 100 (TAG 34 = 3)?
> > > > >
> > > > > Thank you in advance
> > > > >
> > > > > Stefano Ferrari
> > > > >
> > > >
> > >
> >
>
[ original email was from Olexiy Getmanchuk - alexeyg@in4reach.com ]
Dean,
Thanks a lot for you explanation.
I wish them to be incorporated in the most recent 4.4 specification, since now from that spec it’s not so obvious.
Then, just in case, should this rule to be applied to all 4.xx FIX specifications?
> Olexiy,
>
> I can be very wrong sometimes and no one hesitates to disagree with me…
>
> In a SequenceReset/GapFill=Y NewSeqNo is logically limited to the range noted in the ResendRequest it answers plus 1. NewSeqNo must be “the value of the next sequence number immediately following the … sequence numbers being skipped.” For your intrepretation to be correct the description would have to be “the value of the next sequence number to be expected by the receiver.” But that’s the definition when GapFill=N.
>
> In your example the GapFill is not skipping messages 1-2000, only 1-100, so NewSeqNo should be 101.
>
> > Since you, Dean, are a member of Certifiaction group it’s hard to argue with you…
> >
> > But’ll try =)
> > Let’s consider such scenario:
> > FIX Session is established correctly and everything is fine.
> >
> > Client SeqNums (in/out): 1000:2000
> > Server SeqNums (in/out): 2000:1000
> >
> > Then Server sends Resend Request 1-100.
> >
> > Let’s suppose that client don’t want to send those messages, issue SeqReset-GapFill and after that TestRequest (as example).
> >
> > In my opinion, next actions should be as following:
> >
> > Client: SeqReset-GapFill (SeqNum=1, GapFillFlag=Y, NewSeqNo=2001)
> > Client: TestRequest (seqNum=2001)
> > Server: Heartbeat (seqNum=1001)
> >
> > Am I wrong?
> >
> > Thanks,
> > Olexiy.
> >
> > > The GapFill is just that - filling the range of messages that the Exchange says it missed 1-99. Message 100 was consumed by Login, the Exchange processed it, and it would be illegal for the Client to reuse Seq=100 for another message. The Exchange should not have asked for another resend.
> > >
> > >
> > > > Hi All,
> > > >
> > > > Quote from FIX 4.2 spec for MsgType=4(Sequence Reset (Gap Fill))
> > > > "
> > > > The message in all situations specifies
> > > > NewSeqNo to reset as the value of the next sequence number immediately following the messages and/or sequence numbers being skipped.
> > > > "
> > > >
> > > > Therefore, EMail from client has to have SeqNum=100, not 101 and Exchange asked for missed 100 correctly.
> > > >
> > > > WBR,
> > > > Olexiy.
> > > >
> > > > > Stefano,
> > > > >
> > > > > Here’s a summary of your dialog:
> > > > > Client: Login Seq=100
> > > > > Exchng: Login Seq=1
> > > > > Exchng: Resend Seq=1-99
> > > > > Client: GapFill NewSeqNo=100
> > > > > Client: EMail Seq=101
> > > > > Exchng: Resend Seq=100-infinity
> > > > >
> > > > > The Client responded correctly to ResendRequest with GapFill/NewSeqNo=100, one beyond what the Exchange asked for. The Exchange already has Seq=100 from the Client in hand - its Login message - and should have been expecting Seq=101 after processing the GapFill.
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > we are having a discussion with our customer regarding the following Fix Standard 4.2 sequence of messages, can you help us in understanding if Exchange or Client is not correctly bahaving?
> > > > > >
> > > > > > Client Login Request:
> > > > > > 8=FIX.4.29=14835=A50=BNL00334=10049=042556=TLX43=N52=20030716-08:36
> > > > > > :41.00098=0108=8095=4996=1BNL003 BnL003
> > > > > > 93=189=110=135
> > > > > >
> > > > > > Exchange Login Response:
> > > > > > 8=FIX.4.29=13235=A49=TLX56=042534=150=152=20030716-08:36:42.3
> > > > > > 38369=098=0108=8095=3296=BNL003 0425
> > > > > > 93=889=BK39835910=249
> > > > > >
> > > > > > Exchange Resend Request message from message sequence number 1 (TAG 7) to 99 (TAG 99)
> > > > > > 8=FIX.4.29=8235=249=TLX56=042534=250=152=20030716-08:36:42.35
> > > > > > 47=116=9993=889=BK39835910=148
> > > > > >
> > > > > > Client Sequence Reset message with TAG 36= 100:
> > > > > > 8=FIX.4.29=12135=450=BNL00334=149=042556=TLX43=Y52=20030716-08:37:0
> > > > > > 3.000122=20030716-08:37:03.00036=100123=Y93=889=BK39835910=143
> > > > > >
> > > > > > New Message sent by the Client:
> > > > > > 8=FIX.4.29=9435=c50=BNL00334=10149=042556=TLX52=20030716-08:37:03.00
> > > > > > 0320=LIST321=393=889=BK39835910=177
> > > > > >
> > > > > > New Resend Request from Exchange asking for Message Sequence Number 100:
> > > > > > 8=FIX.4.29=8335=249=TLX56=042534=350=152=20030716-08:37:04.55
> > > > > > 77=10016=093=889=BK39835910=184
> > > > > >
> > > > > > - Is correct the behaviour of the Exchange or the Exchange should not have requested the last Resend Request message (TAG 34 = 3)?
> > > > > >
> > > > > > - Is correct the behaviour of the Client or the Client should have sent a Sequence Reset Gap Fill message with TAG 36 = 101 instead of 100 (TAG 34 = 3)?
> > > > > >
> > > > > > Thank you in advance
> > > > > >
> > > > > > Stefano Ferrari
> > > > > >
> > > > >
> > > >
> > >
> >
>
[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
Vlad,
To answer your specific questions:
- Until the gaps are filled by the client, the exchange should be prepared to warehouse (i.e. NOT process) some number of input messages. If the client doesn’t gap-fill in a reasonably short time it’s fair to force logout.
- The NewSeqNo field serves to mark the upper limit of the range being addressed by the GapFill. If in your scenario (resend 1-99) the client wants to resend message 50 and omit the balance, here’s what the client would send:
-> GapFill Seq=1, NewSeqNo=50
-> Resend of message 50
-> GapFill Seq=51, NewSeqNo=100
The exchange would consume sequences 1-49 (first message), process message 50, consume sequences 51-99 (third message), consume sequence 100 (used in the Login), process warehoused message 101, and expect sequence 102 as the next input from the client.
Hello Dean,
I’ve been reading this post and am slightly confused. I am comparing your explanation of this scenario with the fix 4.2 spec (Specification Document with Errata as of 20010501 (PDF, 1.5MB)).
Question: Does the sequence number in the original Login message from the client have any bearing on the problem? As in, the message came in with a sequence number of 100, so the client should not, under the circumstances in that scenario send another message with a sequence number of 100. Ok, but in that case, what is the point of field 36 anyway? The exchange has to keep track of what sequence numbers it has received from the client anyway (my understanding of your explanation), so why even bother with a NewSeqNum flag (that may be irrelevant but that makes me think that I am misinterpreting something in your reply).
Question two: In a slightly different scenario, for instance:
Client: Login Seq=100
Exchng: Login Seq=1
Exchng: Resend Seq=1-99
>>>CLIENT<<<<: SomeMsg with Seq = 101
Client: GapFill NewSeqNo=100
What should the exchange do with this message. Should it:
- Ignore it completely
- Ignore the message, but ‘consume’ it’s sequence number? So that at the end of this scenario, the Exchange should expect the next incoming message to have a sequence number of 102, even if the NewSeqNum from the client state 100.
Lastly, you say in reply to Olexiy:
“For your intrepretation to be correct the description would have to be “the value of the next sequence number to be expected by the receiver.” But that’s the definition when GapFill=N.”
Looking at the 4.2 specification, I honnestly can’t find a definition for the case where GapFill = N.
I can only find the definition which both of you quote, and which I admit to interpreting as:
"NewSeqNum is the value of the next sequence number to be expected by the receiver."
To summarize this epic post 
- if the exchange has requested a resend request, what should it do with messages that arrive before the resend/or sequence reset has been sent.
- why have a NewSeqNum field at all. If GapFill is not present, NewSeqNum should not be a required field (again this may be irrelevant but isn’t it confusing? I wonder how many people’s first interpretation is that the NewSeqNum flag is the number to be expected by the receiver).
Any reply would be appreciated.
Thanks,
Vlad
Vladimir Stanishev
Barclays Capital
vladimir.stanishev@barcap.com
> Dean,
>
> Thanks a lot for you explanation.
> I wish them to be incorporated in the most recent 4.4 specification, since now from that spec it’s not so obvious.
>
> Then, just in case, should this rule to be applied to all 4.xx FIX specifications?
>
> > Olexiy,
> >
> > I can be very wrong sometimes and no one hesitates to disagree with me…
> >
> > In a SequenceReset/GapFill=Y NewSeqNo is logically limited to the range noted in the ResendRequest it answers plus 1. NewSeqNo must be “the value of the next sequence number immediately following the … sequence numbers being skipped.” For your intrepretation to be correct the description would have to be “the value of the next sequence number to be expected by the receiver.” But that’s the definition when GapFill=N.
> >
> > In your example the GapFill is not skipping messages 1-2000, only 1-100, so NewSeqNo should be 101.
> >
> > > Since you, Dean, are a member of Certifiaction group it’s hard to argue with you…
> > >
> > > But’ll try =)
> > > Let’s consider such scenario:
> > > FIX Session is established correctly and everything is fine.
> > >
> > > Client SeqNums (in/out): 1000:2000
> > > Server SeqNums (in/out): 2000:1000
> > >
> > > Then Server sends Resend Request 1-100.
> > >
> > > Let’s suppose that client don’t want to send those messages, issue SeqReset-GapFill and after that TestRequest (as example).
> > >
> > > In my opinion, next actions should be as following:
> > >
> > > Client: SeqReset-GapFill (SeqNum=1, GapFillFlag=Y, NewSeqNo=2001)
> > > Client: TestRequest (seqNum=2001)
> > > Server: Heartbeat (seqNum=1001)
> > >
> > > Am I wrong?
> > >
> > > Thanks,
> > > Olexiy.
> > >
> > > > The GapFill is just that - filling the range of messages that the Exchange says it missed 1-99. Message 100 was consumed by Login, the Exchange processed it, and it would be illegal for the Client to reuse Seq=100 for another message. The Exchange should not have asked for another resend.
> > > >
> > > >
> > > > > Hi All,
> > > > >
> > > > > Quote from FIX 4.2 spec for MsgType=4(Sequence Reset (Gap Fill))
> > > > > "
> > > > > The message in all situations specifies
> > > > > NewSeqNo to reset as the value of the next sequence number immediately following the messages and/or sequence numbers being skipped.
> > > > > "
> > > > >
> > > > > Therefore, EMail from client has to have SeqNum=100, not 101 and Exchange asked for missed 100 correctly.
> > > > >
> > > > > WBR,
> > > > > Olexiy.
> > > > >
> > > > > > Stefano,
> > > > > >
> > > > > > Here’s a summary of your dialog:
> > > > > > Client: Login Seq=100
> > > > > > Exchng: Login Seq=1
> > > > > > Exchng: Resend Seq=1-99
> > > > > > Client: GapFill NewSeqNo=100
> > > > > > Client: EMail Seq=101
> > > > > > Exchng: Resend Seq=100-infinity
> > > > > >
> > > > > > The Client responded correctly to ResendRequest with GapFill/NewSeqNo=100, one beyond what the Exchange asked for. The Exchange already has Seq=100 from the Client in hand - its Login message - and should have been expecting Seq=101 after processing the GapFill.
> > > > > >
> > > > > > > Hi All,
> > > > > > >
> > > > > > > we are having a discussion with our customer regarding the following Fix Standard 4.2 sequence of messages, can you help us in understanding if Exchange or Client is not correctly bahaving?
> > > > > > >
> > > > > > > Client Login Request:
> > > > > > > 8=FIX.4.29=14835=A50=BNL00334=10049=042556=TLX43=N52=20030716-08:36
> > > > > > > :41.00098=0108=8095=4996=1BNL003 BnL003
> > > > > > > 93=189=110=135
> > > > > > >
> > > > > > > Exchange Login Response:
> > > > > > > 8=FIX.4.29=13235=A49=TLX56=042534=150=152=20030716-08:36:42.3
> > > > > > > 38369=098=0108=8095=3296=BNL003 0425
> > > > > > > 93=889=BK39835910=249
> > > > > > >
> > > > > > > Exchange Resend Request message from message sequence number 1 (TAG 7) to 99 (TAG 99)
> > > > > > > 8=FIX.4.29=8235=249=TLX56=042534=250=152=20030716-08:36:42.35
> > > > > > > 47=116=9993=889=BK39835910=148
> > > > > > >
> > > > > > > Client Sequence Reset message with TAG 36= 100:
> > > > > > > 8=FIX.4.29=12135=450=BNL00334=149=042556=TLX43=Y52=20030716-08:37:0
> > > > > > > 3.000122=20030716-08:37:03.00036=100123=Y93=889=BK39835910=143
> > > > > > >
> > > > > > > New Message sent by the Client:
> > > > > > > 8=FIX.4.29=9435=c50=BNL00334=10149=042556=TLX52=20030716-08:37:03.00
> > > > > > > 0320=LIST321=393=889=BK39835910=177
> > > > > > >
> > > > > > > New Resend Request from Exchange asking for Message Sequence Number 100:
> > > > > > > 8=FIX.4.29=8335=249=TLX56=042534=350=152=20030716-08:37:04.55
> > > > > > > 77=10016=093=889=BK39835910=184
> > > > > > >
> > > > > > > - Is correct the behaviour of the Exchange or the Exchange should not have requested the last Resend Request message (TAG 34 = 3)?
> > > > > > >
> > > > > > > - Is correct the behaviour of the Client or the Client should have sent a Sequence Reset Gap Fill message with TAG 36 = 101 instead of 100 (TAG 34 = 3)?
> > > > > > >
> > > > > > > Thank you in advance
> > > > > > >
> > > > > > > Stefano Ferrari
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>