Thread: [Quickfix-developers] Logon contains ResetSeqNumFlag=Y, reseting sequence numbers to 1
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: Alexey Z. <ale...@in...> - 2005-06-30 14:05:05
|
Hi, I've got a new sequencing problem and I want to know who is right in this situation. In the CVS version QF reset sequence number if ResetSeqNumFlag is present in logon message. So I fail in the following scenario: My QF initiator connects to a third-part server (Currenex) with the flag and receives logon message with sequence number 1 and with this flag too. QF (Session class) resets sequence number, and the next message I send has sequence number 1. So, the server sends me logout - "MsgSeqNum too low, expecting 2 but received 1". Who is right? Should QF reset sequence number on logon confirmation or the server shouldn't send the flag, or QF reset is correct? Thank you in advance. -- Regards, Alexey Zubko Infinium Capital Corporation (416) 360-7000 ext. 305 |
|
From: Oren M. <or...@qu...> - 2005-06-30 16:27:57
|
Well, here is what the spec says on the subject: "When using the ResetSeqNumFlag to maintain 24 hour connectivity and =20 establish a new set of sequence numbers, the process should be as =20 follows. Both sides should agree on a reset time and the party that =20 will be the initiator of the process. Note that the initiator of the =20= ResetSeqNum process may be different than the initiator of the Logon =20 process. One side will initiate the process by sending a TestRequest =20 and wait for a Heartbeat in response to ensure of no sequence number =20 gaps. Once the Heartbeat has been received, the initiator should =20 send a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. =20 The acceptor should respond with a Logon with ResetSeqNumFlag set to =20 Y and with MsgSeqNum of 1. At this point new messages from either =20 side should continue with MsgSeqNum of 2. It should be noted that =20 once the initiator sends the Logon with the ResetSeqNumFlag set, the =20 acceptor must obey this request and the message with the last =20 sequence number transmitted =93yesterday=94 may no longer be available. = =20 The connection should be shutdown and manual intervention taken if =20 this process is initiated but not followed properly." So it would seem to me that when they send a Logon with the =20 ResetSeqNumFlag set, the first thing QF should do is send a Logon =20 message with a MsgSeqNum of 1, followed by your message with a =20 sequence number of 2. Is this message going out? If not then that =20 could be a problem. I don't think we have a test case for an =20 initiator processing a ResetSeqNumFlag, so I can imagine this =20 scenario might not be handled correctly. --oren On Jun 30, 2005, at 9:04 AM, Alexey Zubko wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20 > html/index.html > QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?=20 > QuickFixFAQ > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi, > > I've got a new sequencing problem and I want to know who is right =20 > in this situation. > > In the CVS version QF reset sequence number if ResetSeqNumFlag is =20 > present in logon message. > > So I fail in the following scenario: > My QF initiator connects to a third-part server (Currenex) with the =20= > flag and receives logon > message with sequence number 1 and with this flag too. QF (Session =20 > class) resets sequence number, > and the next message I send has sequence number 1. So, the server =20 > sends me logout - > "MsgSeqNum too low, expecting 2 but received 1". > > Who is right? Should QF reset sequence number on logon confirmation =20= > or the server shouldn't > send the flag, or QF reset is correct? > > Thank you in advance. > > --=20 > > Regards, > Alexey Zubko > > Infinium Capital Corporation > (416) 360-7000 ext. 305 > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcli= ck > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > |
|
From: Alexey Z. <ale...@in...> - 2005-06-30 17:08:05
|
Oren, It looks like due to the specification the server acts correctly. So, QF initiator should not reset sequence numbers on logon confirmation I think. Here are the logs: QF initiator: 8=FIX.4.2.9=88.35=A.34=1.49=F.52=20050630-13:05:01.022.56=CURRENEX-FXTRADES-FIX.98=0.108=30.141=Y.10=154. 8=FIX.4.2.9=139.35=V.34=1.49=F.52=20050630-13:05:01.304.56=CURRENEX-FXTRADES-FIX.146=1.55=AUD/USD.262=ICMD0.263=1.264=1.265=1.266=Y.267=2.269=0.269=1.10=233. 8=FIX.4.2.9=139.35=V.34=2.49=F.52=20050630-13:05:01.304.56=CURRENEX-FXTRADES-FIX.146=1.55=EUR/USD.262=ICMD1.263=1.264=1.265=1.266=Y.267=2.269=0.269=1.10=253. The server: 8=FIX.4.2.9=84.35=A.49=CURRENEX-FXTRADES-FIX.56=F.34=1.52=20050630-13:05:01.108=30.141=Y.98=0.10=212. 8=FIX.4.2.9=78.35=h.49=CURRENEX-FXTRADES-FIX.56=F.34=2.52=20050630-13:05:01.336=0.340=2.10=202. 8=FIX.4.2.9=133.35=5.49=CURRENEX-FXTRADES-FIX.56=F.34=3.52=20050630-13:05:01.58=MsgSeqNum too low, expecting 2 but received 1 MarketDataRequest.10=045. Regards, Alexey Zubko Infinium Capital Corporation (416) 360-7000 ext. 305 Oren Miller wrote: > Well, here is what the spec says on the subject: > > "When using the ResetSeqNumFlag to maintain 24 hour connectivity and > establish a new set of sequence numbers, the process should be as > follows. Both sides should agree on a reset time and the party that > will be the initiator of the process. Note that the initiator of the > ResetSeqNum process may be different than the initiator of the Logon > process. One side will initiate the process by sending a TestRequest > and wait for a Heartbeat in response to ensure of no sequence number > gaps. Once the Heartbeat has been received, the initiator should > send a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. > The acceptor should respond with a Logon with ResetSeqNumFlag set to > Y and with MsgSeqNum of 1. At this point new messages from either > side should continue with MsgSeqNum of 2. It should be noted that > once the initiator sends the Logon with the ResetSeqNumFlag set, the > acceptor must obey this request and the message with the last > sequence number transmitted “yesterday” may no longer be available. > The connection should be shutdown and manual intervention taken if > this process is initiated but not followed properly." > > So it would seem to me that when they send a Logon with the > ResetSeqNumFlag set, the first thing QF should do is send a Logon > message with a MsgSeqNum of 1, followed by your message with a > sequence number of 2. Is this message going out? If not then that > could be a problem. I don't think we have a test case for an > initiator processing a ResetSeqNumFlag, so I can imagine this > scenario might not be handled correctly. > > --oren > > On Jun 30, 2005, at 9:04 AM, Alexey Zubko wrote: > >> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ >> html/index.html >> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php? >> QuickFixFAQ >> QuickFIX Support: http://www.quickfixengine.org/services.html >> >> Hi, >> >> I've got a new sequencing problem and I want to know who is right in >> this situation. >> >> In the CVS version QF reset sequence number if ResetSeqNumFlag is >> present in logon message. >> >> So I fail in the following scenario: >> My QF initiator connects to a third-part server (Currenex) with the >> flag and receives logon >> message with sequence number 1 and with this flag too. QF (Session >> class) resets sequence number, >> and the next message I send has sequence number 1. So, the server >> sends me logout - >> "MsgSeqNum too low, expecting 2 but received 1". >> >> Who is right? Should QF reset sequence number on logon confirmation >> or the server shouldn't >> send the flag, or QF reset is correct? >> >> Thank you in advance. >> >> -- >> >> Regards, >> Alexey Zubko >> >> Infinium Capital Corporation >> (416) 360-7000 ext. 305 >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >> from IBM. Find simple to follow Roadmaps, straightforward articles, >> informative Webcasts and more! Get everything you need to get up to >> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >> _______________________________________________ >> Quickfix-developers mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >> >> > > |
|
From: Oren M. <or...@qu...> - 2005-06-30 20:05:25
|
Hold off on that patch. I found a bug in it. I'm preparing another. --oren On Jun 30, 2005, at 12:07 PM, Alexey Zubko wrote: > Oren, > > It looks like due to the specification the server acts correctly. > So, QF initiator should not reset sequence numbers on logon =20 > confirmation I think. > > Here are the logs: > > QF initiator: > 8=3DFIX.4.2.9=3D88.35=3DA.34=3D1.49=3DF.52=3D20050630-13:05:01.022.56=3D= CURRENEX-=20 > FXTRADES-FIX.98=3D0.108=3D30.141=3DY.10=3D154. > 8=3DFIX.4.2.9=3D139.35=3DV.34=3D1.49=3DF.52=3D20050630-13:05:01.304.56=3D= CURRENEX-=20 > FXTRADES-FIX.146=3D1.55=3DAUD/USD.262=3DICMD0.263=3D1.264=3D1.265=3D1.26= 6=3DY.=20 > 267=3D2.269=3D0.269=3D1.10=3D233. > 8=3DFIX.4.2.9=3D139.35=3DV.34=3D2.49=3DF.52=3D20050630-13:05:01.304.56=3D= CURRENEX-=20 > FXTRADES-FIX.146=3D1.55=3DEUR/USD.262=3DICMD1.263=3D1.264=3D1.265=3D1.26= 6=3DY.=20 > 267=3D2.269=3D0.269=3D1.10=3D253. > > > The server: > 8=3DFIX.4.2.9=3D84.35=3DA.49=3DCURRENEX-FXTRADES-FIX.56=3DF.=20 > 34=3D1.52=3D20050630-13:05:01.108=3D30.141=3DY.98=3D0.10=3D212. > 8=3DFIX.4.2.9=3D78.35=3Dh.49=3DCURRENEX-FXTRADES-FIX.56=3DF.=20 > 34=3D2.52=3D20050630-13:05:01.336=3D0.340=3D2.10=3D202. > 8=3DFIX.4.2.9=3D133.35=3D5.49=3DCURRENEX-FXTRADES-FIX.56=3DF.=20 > 34=3D3.52=3D20050630-13:05:01.58=3DMsgSeqNum too low, expecting 2 but =20= > received 1 MarketDataRequest.10=3D045. > > > > Regards, Alexey Zubko Infinium Capital Corporation (416) 360-7000 =20 > ext. 305 > > Oren Miller wrote: >> Well, here is what the spec says on the subject: >> >> "When using the ResetSeqNumFlag to maintain 24 hour connectivity =20 >> and establish a new set of sequence numbers, the process should =20 >> be as follows. Both sides should agree on a reset time and the =20 >> party that will be the initiator of the process. Note that the =20 >> initiator of the ResetSeqNum process may be different than the =20 >> initiator of the Logon process. One side will initiate the =20 >> process by sending a TestRequest and wait for a Heartbeat in =20 >> response to ensure of no sequence number gaps. Once the =20 >> Heartbeat has been received, the initiator should send a Logon =20 >> with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. The =20 >> acceptor should respond with a Logon with ResetSeqNumFlag set to =20 >> Y and with MsgSeqNum of 1. At this point new messages from =20 >> either side should continue with MsgSeqNum of 2. It should be =20 >> noted that once the initiator sends the Logon with the =20 >> ResetSeqNumFlag set, the acceptor must obey this request and the =20 >> message with the last sequence number transmitted =93yesterday=94 = may =20 >> no longer be available. The connection should be shutdown and =20 >> manual intervention taken if this process is initiated but not =20 >> followed properly." >> >> So it would seem to me that when they send a Logon with the =20 >> ResetSeqNumFlag set, the first thing QF should do is send a Logon =20= >> message with a MsgSeqNum of 1, followed by your message with a =20 >> sequence number of 2. Is this message going out? If not then =20 >> that could be a problem. I don't think we have a test case for =20 >> an initiator processing a ResetSeqNumFlag, so I can imagine this =20= >> scenario might not be handled correctly. >> >> --oren >> >> On Jun 30, 2005, at 9:04 AM, Alexey Zubko wrote: >> >>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/=20 >>> doc/ html/indexhtml. >>> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php? =20 >>> QuickFixFAQ >>> QuickFIX Support: http://www.quickfixengine.org/services.html >>> >>> Hi, >>> >>> I've got a new sequencing problem and I want to know who is =20 >>> right in this situation. >>> >>> In the CVS version QF reset sequence number if ResetSeqNumFlag =20 >>> is present in logon message. >>> >>> So I fail in the following scenario: >>> My QF initiator connects to a third-part server (Currenex) with =20 >>> the flag and receives logon >>> message with sequence number 1 and with this flag too. QF =20 >>> (Session class) resets sequence number, >>> and the next message I send has sequence number 1. So, the =20 >>> server sends me logout - >>> "MsgSeqNum too low, expecting 2 but received 1". >>> >>> Who is right? Should QF reset sequence number on logon =20 >>> confirmation or the server shouldn't >>> send the flag, or QF reset is correct? >>> >>> Thank you in advance. >>> >>> --=20 >>> >>> Regards, >>> Alexey Zubko >>> >>> Infinium Capital Corporation >>> (416) 360-7000 ext. 305 >>> >>> >>> >>> ------------------------------------------------------- >>> SF.Net email is sponsored by: Discover Easy Linux Migration =20 >>> Strategies >>> from IBM. Find simple to follow Roadmaps, straightforward articles, >>> informative Webcasts and more! Get everything you need to get up to >>> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dc= lick >>> _______________________________________________ >>> Quickfix-developers mailing list >>> Qui...@li... >>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >>> >>> >> >> |
