Imported from previous forum
So, I’ve looked at quckfix’s testcases and found out some strangeness, just simple scenario:
conventional signs:
< - received
- send
1 < Logon{ Header: { BeginString: “FIX.4.2”, BodyLength: 57, MsgType: “A”, SenderCompID: “TW”, TargetCompID: “ISLD”, MsgSeqNum: 1, SendingTime: “20120913-08:52:27.000”}, EncryptMethod: 0, HeartBtInt: 30, Trailer: { CheckSum: “019”}}
2 > Logon{ Header: { BeginString: “FIX.4.2”, MsgType: “A”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 1, SendingTime: “20120913-08:52:27.322”}, EncryptMethod: 0, HeartBtInt: 30}
3 < SequenceReset{ Header: { BeginString: “FIX.4.2”, BodyLength: 58, MsgType: “4”, SenderCompID: “TW”, TargetCompID: “ISLD”, MsgSeqNum: 10, SendingTime: “20120913-08:52:27.000”}, GapFillFlag: “Y”, NewSeqNo: 20, Trailer: { CheckSum: “084”}}
4 < TestRequest{ Header: { BeginString: “FIX.4.2”, BodyLength: 56, MsgType: “1”, SenderCompID: “TW”, TargetCompID: “ISLD”, MsgSeqNum: 20, SendingTime: “20120913-08:52:27.000”}, TestReqID: “HELLO”, Trailer: { CheckSum: “096”}}
5 > ResendRequest{ Header: { BeginString: “FIX.4.2”, MsgType: “2”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 2, SendingTime: “20120913-08:52:27.324”}, BeginSeqNo: 2, EndSeqNo: 0}
6 < Logout{ Header: { BeginString: “FIX.4.2”, BodyLength: 45, MsgType: “5”, SenderCompID: “TW”, TargetCompID: “ISLD”, MsgSeqNum: 2, SendingTime: “20120913-08:52:27.000”}, Trailer: { CheckSum: “236”}}
7 > Logout{ Header: { BeginString: “FIX.4.2”, MsgType: “5”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 4, SendingTime: “20120913-08:52:27.326”}}
Please pay your attention to lines from 3 to 5, we have two messages running with wrong MsgSeqNum (10 and 20) and we have to send only 1 ResendRequest (according this script) ! Why ? It is nonsense for me, I did find out where this situation is specified into spec… It will be right to send 2 ResendRequest’s:
ResendRequest{ Header: { BeginString: “FIX.4.2”, MsgType: “2”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 2, SendingTime: “20120913-08:52:27.324”}, BeginSeqNo: 2, EndSeqNo: 0}
ResendRequest{ Header: { BeginString: “FIX.4.2”, MsgType: “2”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 3, SendingTime: “20120913-08:52:27.325”}, BeginSeqNo: 2, EndSeqNo: 0}
Could you please comment who know.
Thanks !
Hi Rustam,
you should ignore SeqNum in case of Sequence reset…
So, when you receive line 3 message, set your expected incoming SeqNum to 20 and then reply to Test Request (line 4 message).
Hope this helps
Lanfranco
So, I’ve looked at quckfix’s testcases and found out some strangeness, just simple scenario:
conventional signs:
< - received
- send
1 < Logon{ Header: { BeginString: “FIX.4.2”, BodyLength: 57, MsgType: “A”, SenderCompID: “TW”, TargetCompID: “ISLD”, MsgSeqNum: 1, SendingTime: “20120913-08:52:27.000”}, EncryptMethod: 0, HeartBtInt: 30, Trailer: { CheckSum: “019”}}
2 > Logon{ Header: { BeginString: “FIX.4.2”, MsgType: “A”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 1, SendingTime: “20120913-08:52:27.322”}, EncryptMethod: 0, HeartBtInt: 30}
3 < SequenceReset{ Header: { BeginString: “FIX.4.2”, BodyLength: 58, MsgType: “4”, SenderCompID: “TW”, TargetCompID: “ISLD”, MsgSeqNum: 10, SendingTime: “20120913-08:52:27.000”}, GapFillFlag: “Y”, NewSeqNo: 20, Trailer: { CheckSum: “084”}}
4 < TestRequest{ Header: { BeginString: “FIX.4.2”, BodyLength: 56, MsgType: “1”, SenderCompID: “TW”, TargetCompID: “ISLD”, MsgSeqNum: 20, SendingTime: “20120913-08:52:27.000”}, TestReqID: “HELLO”, Trailer: { CheckSum: “096”}}5 > ResendRequest{ Header: { BeginString: “FIX.4.2”, MsgType: “2”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 2, SendingTime: “20120913-08:52:27.324”}, BeginSeqNo: 2, EndSeqNo: 0}
6 < Logout{ Header: { BeginString: “FIX.4.2”, BodyLength: 45, MsgType: “5”, SenderCompID: “TW”, TargetCompID: “ISLD”, MsgSeqNum: 2, SendingTime: “20120913-08:52:27.000”}, Trailer: { CheckSum: “236”}}
7 > Logout{ Header: { BeginString: “FIX.4.2”, MsgType: “5”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 4, SendingTime: “20120913-08:52:27.326”}}Please pay your attention to lines from 3 to 5, we have two messages running with wrong MsgSeqNum (10 and 20) and we have to send only 1 ResendRequest (according this script) ! Why ? It is nonsense for me, I did find out where this situation is specified into spec… It will be right to send 2 ResendRequest’s:
ResendRequest{ Header: { BeginString: “FIX.4.2”, MsgType: “2”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 2, SendingTime: “20120913-08:52:27.324”}, BeginSeqNo: 2, EndSeqNo: 0}
ResendRequest{ Header: { BeginString: “FIX.4.2”, MsgType: “2”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 3, SendingTime: “20120913-08:52:27.325”}, BeginSeqNo: 2, EndSeqNo: 0}Could you please comment who know.
Thanks !
Hi Rustam,
you should ignore SeqNum in case of Sequence reset…
So, when you receive line 3 message, set your expected incoming SeqNum to 20 and then reply to Test Request (line 4 message).Hope this helps
Lanfranco
Hi Lanfranco,
I’m sorry but you are wrong, please see spec. page 56 (a. Receive Sequence Reset (GapFill) message with MsgSeqNum > than expected sequence number)
3 < SequenceReset{ Header: { BeginString: “FIX.4.2”, BodyLength: 58, MsgType: “4”, SenderCompID: “TW”, TargetCompID: “ISLD”, MsgSeqNum: 10, SendingTime: “20120913-08:52:27.000”}, GapFillFlag: “Y”, NewSeqNo: 20, Trailer: { CheckSum: “084”}}
Why do you want to send a second resend request while you know that you will receive all messages with the first one (EndSeqNo=0)?
So, I’ve looked at quckfix’s testcases and found out some strangeness, just simple scenario:
conventional signs:
< - received
- send
1 < Logon{ Header: { BeginString: “FIX.4.2”, BodyLength: 57, MsgType: “A”, SenderCompID: “TW”, TargetCompID: “ISLD”, MsgSeqNum: 1, SendingTime: “20120913-08:52:27.000”}, EncryptMethod: 0, HeartBtInt: 30, Trailer: { CheckSum: “019”}}
2 > Logon{ Header: { BeginString: “FIX.4.2”, MsgType: “A”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 1, SendingTime: “20120913-08:52:27.322”}, EncryptMethod: 0, HeartBtInt: 30}
3 < SequenceReset{ Header: { BeginString: “FIX.4.2”, BodyLength: 58, MsgType: “4”, SenderCompID: “TW”, TargetCompID: “ISLD”, MsgSeqNum: 10, SendingTime: “20120913-08:52:27.000”}, GapFillFlag: “Y”, NewSeqNo: 20, Trailer: { CheckSum: “084”}}
4 < TestRequest{ Header: { BeginString: “FIX.4.2”, BodyLength: 56, MsgType: “1”, SenderCompID: “TW”, TargetCompID: “ISLD”, MsgSeqNum: 20, SendingTime: “20120913-08:52:27.000”}, TestReqID: “HELLO”, Trailer: { CheckSum: “096”}}5 > ResendRequest{ Header: { BeginString: “FIX.4.2”, MsgType: “2”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 2, SendingTime: “20120913-08:52:27.324”}, BeginSeqNo: 2, EndSeqNo: 0}
6 < Logout{ Header: { BeginString: “FIX.4.2”, BodyLength: 45, MsgType: “5”, SenderCompID: “TW”, TargetCompID: “ISLD”, MsgSeqNum: 2, SendingTime: “20120913-08:52:27.000”}, Trailer: { CheckSum: “236”}}
7 > Logout{ Header: { BeginString: “FIX.4.2”, MsgType: “5”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 4, SendingTime: “20120913-08:52:27.326”}}Please pay your attention to lines from 3 to 5, we have two messages running with wrong MsgSeqNum (10 and 20) and we have to send only 1 ResendRequest (according this script) ! Why ? It is nonsense for me, I did find out where this situation is specified into spec… It will be right to send 2 ResendRequest’s:
ResendRequest{ Header: { BeginString: “FIX.4.2”, MsgType: “2”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 2, SendingTime: “20120913-08:52:27.324”}, BeginSeqNo: 2, EndSeqNo: 0}
ResendRequest{ Header: { BeginString: “FIX.4.2”, MsgType: “2”, SenderCompID: “ISLD”, TargetCompID: “TW”, MsgSeqNum: 3, SendingTime: “20120913-08:52:27.325”}, BeginSeqNo: 2, EndSeqNo: 0}Could you please comment who know.
Thanks !
Why do you want to send a second resend request while you know that you will receive all messages with the first one (EndSeqNo=0)?
I want to send second ResendRequest according to specifications (FIXT.1.1 “message recovery”, page 12). Nowhere specified that I should ignore TestRequest. I have to send ResendRequest or Heartbeat, but that script just send one ResendRequest. It’s seems to me one is not correspond specification.
I would like to remind that I’ve got this script from quckfix tests - 10_MsgSeqNumGreater.def
Actually there should be something in specifications which explains that incoming messages with too high sequence numbers may be ignored if we are already waiting for a ResendRequest reply. In your case, the counterpart sends a ResendRequest after receiving the message 3 and ignores the message 4 awaiting the reply of his ResendRequest.
Searching quickly, I found in FIXT 1.1 specifications: FIX Session-level State Matrix, state 12 (page 40)
"Awaiting/Processing Response to ResendRequest
Process requested MsgSeqNum PossDupFlag=Y resent messages and/or SequenceReset-Gap Fill messages from counterparty. Queue incoming messages with MsgSeqNum too high"
Why do you want to send a second resend request while you know that you will receive all messages with the first one (EndSeqNo=0)?
I want to send second ResendRequest according to specifications (FIXT.1.1 “message recovery”, page 12). Nowhere specified that I should ignore TestRequest. I have to send ResendRequest or Heartbeat, but that script just send one ResendRequest. It’s seems to me one is not correspond specification.
I would like to remind that I’ve got this script from quckfix tests - 10_MsgSeqNumGreater.def
Actually there should be something in specifications which explains that incoming messages with too high sequence numbers may be ignored if we are already waiting for a ResendRequest reply. In your case, the counterpart sends a ResendRequest after receiving the message 3 and ignores the message 4 awaiting the reply of his ResendRequest.
Searching quickly, I found in FIXT 1.1 specifications: FIX Session-level State Matrix, state 12 (page 40)
"Awaiting/Processing Response to ResendRequest
Process requested MsgSeqNum PossDupFlag=Y resent messages and/or SequenceReset-Gap Fill messages from counterparty. Queue incoming messages with MsgSeqNum too high"
What does it mean: “Queue incoming messages with MsgSeqNum too high”? It doesn’t seem to be ignore message…
Actually there should be something in specifications which explains that incoming messages with too high sequence numbers may be ignored if we are already waiting for a ResendRequest reply. In your case, the counterpart sends a ResendRequest after receiving the message 3 and ignores the message 4 awaiting the reply of his ResendRequest.
Searching quickly, I found in FIXT 1.1 specifications: FIX Session-level State Matrix, state 12 (page 40)
"Awaiting/Processing Response to ResendRequest
Process requested MsgSeqNum PossDupFlag=Y resent messages and/or SequenceReset-Gap Fill messages from counterparty. Queue incoming messages with MsgSeqNum too high"
What does it mean: “Queue incoming messages with MsgSeqNum too high”? It doesn’t seem to be ignore message…
There are two options:
- Either you send a ResendRequest from 2 to 10 and you queue messages with sequence numbers higher than 10. When you receive the message n°10, you can then process messages of your queue. However you take the responsability to treat queued messages of your counterpart with a delay.
- Or you send a ResendRequest from 2 to 0 (no limit), then you don’t need to queue messages since you expect the counterpart to resend them. When you receive the message n°10, you can assume your ResendRequest is complete and stop ignoring messages with too high sequence numbers (it means if the next message is not the n°11, then you need to send a second ResendRequest).
Normally these two approaches should be discussed in specifications (to check). I think there was already a discussion about it in the forum too.
Actually there should be something in specifications which explains that incoming messages with too high sequence numbers may be ignored if we are already waiting for a ResendRequest reply. In your case, the counterpart sends a ResendRequest after receiving the message 3 and ignores the message 4 awaiting the reply of his ResendRequest.
Searching quickly, I found in FIXT 1.1 specifications: FIX Session-level State Matrix, state 12 (page 40)
"Awaiting/Processing Response to ResendRequest
Process requested MsgSeqNum PossDupFlag=Y resent messages and/or SequenceReset-Gap Fill messages from counterparty. Queue incoming messages with MsgSeqNum too high"
What does it mean: “Queue incoming messages with MsgSeqNum too high”? It doesn’t seem to be ignore message…
There are two options:
- Either you send a ResendRequest from 2 to 10 and you queue messages with sequence numbers higher than 10. When you receive the message n°10, you can then process messages of your queue. However you take the responsability to treat queued messages of your counterpart with a delay.
- Or you send a ResendRequest from 2 to 0 (no limit), then you don’t need to queue messages since you expect the counterpart to resend them. When you receive the message n°10, you can assume your ResendRequest is complete and stop ignoring messages with too high sequence numbers (it means if the next message is not the n°11, then you need to send a second ResendRequest).
Normally these two approaches should be discussed in specifications (to check). I think there was already a discussion about it in the forum too.