Thread: [Quickfix-developers] RE: Logout reason
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: Francis G. <fr...@at...> - 2005-06-15 00:58:03
|
Oren, You're right QF did send a resend request but the counterparty closed the socket so I didn't notice. (see log below) The "sequence number too high" message is from the client (initiator) point of view. It appears that the counterparty does not send a logoff or a session rejection message; it just closes the socket when it receives a MsgSeqNum that is lower than what it expects. BTW it's not a QF acceptor but a custom 3rd party server. This is why the only solution I see is to increase the setNextSenderMsgSeqNum by 1000 every time the socket drops during logon, but I'm not comfortable with such a kludge; what if there are other conditions that cause the socket to drop? Comments welcome. So to conclude, it does not appear to be a QF issue after all because the acceptor side does not send any notification that the logon failed. 20050613-20:26:19 : Created session 20050613-20:26:19 : Connecting to 127.0.0.1 on port 10501 20050613-20:26:19 : Connection succeeded 20050613-20:26:19 : Initiated logon request 20050613-20:26:19 : Received logon response 20050613-20:26:19 : MsgSeqNum too high, expecting 1 but received 481 20050613-20:26:19 : Socket Error: Connection reset by peer. 20050613-20:26:19 : Disconnecting 20050613-20:26:19 : Sent ResendRequest FROM: 1 TO: 0 Thanks, Francis |
|
From: Francis G. <fr...@at...> - 2005-06-16 00:35:18
|
Oren, You're right QF did send a resend request but the counterparty closed the socket so I didn't notice. (see log below) The "sequence number too high" message is from the client (initiator) point of view. It appears that the counterparty does not send a logoff or a session rejection message; it just closes the socket when it receives a MsgSeqNum that is lower than what it expects. BTW it's not a QF acceptor but a custom 3rd party server. This is why the only solution I see is to increase the setNextSenderMsgSeqNum by 1000 every time the socket drops during logon, but I'm not comfortable with such a kludge; what if there are other conditions that cause the socket to drop? Comments welcome. So to conclude, it does not appear to be a QF issue after all because the acceptor side does not send any notification that the logon failed. 20050613-20:26:19 : Created session 20050613-20:26:19 : Connecting to 127.0.0.1 on port 10501 20050613-20:26:19 : Connection succeeded 20050613-20:26:19 : Initiated logon request 20050613-20:26:19 : Received logon response 20050613-20:26:19 : MsgSeqNum too high, expecting 1 but received 481 20050613-20:26:19 : Socket Error: Connection reset by peer. 20050613-20:26:19 : Disconnecting 20050613-20:26:19 : Sent ResendRequest FROM: 1 TO: 0 Thanks, Francis |
|
From: Oren M. <or...@qu...> - 2005-06-16 16:33:09
|
Yeah, this behavior is actually what the FPL recommends. When receiving a sequence number that is too low, you are supposed to kill the connection because there isn't really anything you can do automatically. In fact I believe this is the one scenario where the protocol document states that manual intervention is required. Here is the exact quote: "If the incoming message has a sequence number less than expected and the PossDupFlag is not set, it indicates a serious error. It is strongly recommended that the session be terminated and manual intervention be initiated." So really the third party engine is doing the right thing. You'll find that QF would do exact same thing in this situation. If you really want to start the sequence numbers from scratch, you should reset you sequence numbers and send your logon with the ResetSeqNum flag. This can result in loss of messages if you are not careful. --oren ----- Original Message ----- From: "Francis Gingras" <fr...@at...> To: <qui...@li...> Sent: Wednesday, June 15, 2005 7:35 PM Subject: [Quickfix-developers] RE: Logout reason > 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 > > Oren, > > You're right QF did send a resend request but the counterparty closed the > socket so I didn't notice. (see log below) > > The "sequence number too high" message is from the client (initiator) > point > of view. It appears that the counterparty does not send a logoff or a > session rejection message; it just closes the socket when it receives a > MsgSeqNum that is lower than what it expects. BTW it's not a QF acceptor > but a custom 3rd party server. > > This is why the only solution I see is to increase the > setNextSenderMsgSeqNum by 1000 every time the socket drops during logon, > but > I'm not comfortable with such a kludge; what if there are other conditions > that cause the socket to drop? Comments welcome. > > So to conclude, it does not appear to be a QF issue after all because the > acceptor side does not send any notification that the logon failed. > > 20050613-20:26:19 : Created session > 20050613-20:26:19 : Connecting to 127.0.0.1 on port 10501 > 20050613-20:26:19 : Connection succeeded > 20050613-20:26:19 : Initiated logon request > 20050613-20:26:19 : Received logon response > 20050613-20:26:19 : MsgSeqNum too high, expecting 1 but received 481 > 20050613-20:26:19 : Socket Error: Connection reset by peer. > 20050613-20:26:19 : Disconnecting > 20050613-20:26:19 : Sent ResendRequest FROM: 1 TO: 0 > > Thanks, > > Francis > > > > > ------------------------------------------------------- > 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: Brian E. <azz...@ya...> - 2005-06-16 18:12:38
|
Oren - Some people have been using tag 789 (NextExpectedMsgSeqNum), introduced in FIX 4.4, as a way to handle sequence number too low problems (the CME does this). Although it's still not a FIX standard (the FIX 4.4 use of this tag is optional and on Logon messages only, but may become mandatory in 4.5), it's a really nice way to recover from these situations. The acceptor, when detecting a message too low, sends a Logout message with tag 789 set to the expected sequence number. The initiator can then adjust its sequence number and attempt to log in again. It's a lot cleaner way of recovering from a catastrophic client-side failure than resetting both sequence numbers. If the initiator had some sort of problem that prevents it from being able to resend any gaps, but does NOT want to miss any gaps on the acceptor side, it's really the only clean solution. In most cases, the initiator is definitely going to want the ExecutionReports that have queued up since its failure, but may not have the messages that were sent prior to its failure (or may not want to send them - stale order messages are potentially a HUGE risk, so why submit them?). The use of this tag is VERY popular among the developers that are connecting to my system and has been equally well-received by the CME community. Hopefully, its use will be picked up in 4.5. Speaking of logouts, I haven't noticed any changes to Session.cpp in regards to using the "what" string in RejectLogon to populate the Text field in a Logout message. You seemed to think it was a good idea last month - I could resend the patch if you want (I haven't really done much with CVS and the patch is trivial). - Brian Erst Thynk Software, Inc. --- Oren Miller <or...@qu...> 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 > > Yeah, this behavior is actually what the FPL recommends. When > receiving a > sequence number that is too low, you are supposed to kill the > connection > because there isn't really anything you can do automatically. In > fact I > believe this is the one scenario where the protocol document states > that > manual intervention is required. Here is the exact quote: "If the > incoming > message has a sequence number less than expected and the PossDupFlag > is not > set, it indicates a serious error. It is strongly recommended that > the > session be terminated and manual intervention be initiated." > > So really the third party engine is doing the right thing. You'll > find that > QF would do exact same thing in this situation. > > If you really want to start the sequence numbers from scratch, you > should > reset you sequence numbers and send your logon with the ResetSeqNum > flag. > This can result in loss of messages if you are not careful. > > --oren > > ----- Original Message ----- > From: "Francis Gingras" <fr...@at...> > To: <qui...@li...> > Sent: Wednesday, June 15, 2005 7:35 PM > Subject: [Quickfix-developers] RE: Logout reason > > > > 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 > > > > Oren, > > > > You're right QF did send a resend request but the counterparty > closed the > > socket so I didn't notice. (see log below) > > > > The "sequence number too high" message is from the client > (initiator) > > point > > of view. It appears that the counterparty does not send a logoff > or a > > session rejection message; it just closes the socket when it > receives a > > MsgSeqNum that is lower than what it expects. BTW it's not a QF > acceptor > > but a custom 3rd party server. > > > > This is why the only solution I see is to increase the > > setNextSenderMsgSeqNum by 1000 every time the socket drops during > logon, > > but > > I'm not comfortable with such a kludge; what if there are other > conditions > > that cause the socket to drop? Comments welcome. > > > > So to conclude, it does not appear to be a QF issue after all > because the > > acceptor side does not send any notification that the logon failed. > > > > 20050613-20:26:19 : Created session > > 20050613-20:26:19 : Connecting to 127.0.0.1 on port 10501 > > 20050613-20:26:19 : Connection succeeded > > 20050613-20:26:19 : Initiated logon request > > 20050613-20:26:19 : Received logon response > > 20050613-20:26:19 : MsgSeqNum too high, expecting 1 but received > 481 > > 20050613-20:26:19 : Socket Error: Connection reset by peer. > > 20050613-20:26:19 : Disconnecting > > 20050613-20:26:19 : Sent ResendRequest FROM: 1 TO: 0 > > > > Thanks, > > > > Francis > > > > > > > > > > ------------------------------------------------------- > > 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 > > > > > > ------------------------------------------------------- > 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-16 19:30:38
|
Thanks Brian, I wasn't aware of this field. I've found your patch from your earlier posting. It just slipped through the cracks. I'll get it in. Usually if you want to make sure that something doesn't slip through it's best to add it to the bugtracker: http://www.quickfixengine.org/bugtracker/ I added an issue for this to make sure it won't slip again: http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=80&pos= --oren ----- Original Message ----- From: "Brian Erst" <azz...@ya...> To: "Oren Miller" <or...@qu...>; "Francis Gingras" <fr...@at...>; <qui...@li...> Sent: Thursday, June 16, 2005 1:12 PM Subject: Re: [Quickfix-developers] RE: Logout reason 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 Oren - Some people have been using tag 789 (NextExpectedMsgSeqNum), introduced in FIX 4.4, as a way to handle sequence number too low problems (the CME does this). Although it's still not a FIX standard (the FIX 4.4 use of this tag is optional and on Logon messages only, but may become mandatory in 4.5), it's a really nice way to recover from these situations. The acceptor, when detecting a message too low, sends a Logout message with tag 789 set to the expected sequence number. The initiator can then adjust its sequence number and attempt to log in again. It's a lot cleaner way of recovering from a catastrophic client-side failure than resetting both sequence numbers. If the initiator had some sort of problem that prevents it from being able to resend any gaps, but does NOT want to miss any gaps on the acceptor side, it's really the only clean solution. In most cases, the initiator is definitely going to want the ExecutionReports that have queued up since its failure, but may not have the messages that were sent prior to its failure (or may not want to send them - stale order messages are potentially a HUGE risk, so why submit them?). The use of this tag is VERY popular among the developers that are connecting to my system and has been equally well-received by the CME community. Hopefully, its use will be picked up in 4.5. Speaking of logouts, I haven't noticed any changes to Session.cpp in regards to using the "what" string in RejectLogon to populate the Text field in a Logout message. You seemed to think it was a good idea last month - I could resend the patch if you want (I haven't really done much with CVS and the patch is trivial). - Brian Erst Thynk Software, Inc. --- Oren Miller <or...@qu...> 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 > > Yeah, this behavior is actually what the FPL recommends. When > receiving a > sequence number that is too low, you are supposed to kill the > connection > because there isn't really anything you can do automatically. In > fact I > believe this is the one scenario where the protocol document states > that > manual intervention is required. Here is the exact quote: "If the > incoming > message has a sequence number less than expected and the PossDupFlag > is not > set, it indicates a serious error. It is strongly recommended that > the > session be terminated and manual intervention be initiated." > > So really the third party engine is doing the right thing. You'll > find that > QF would do exact same thing in this situation. > > If you really want to start the sequence numbers from scratch, you > should > reset you sequence numbers and send your logon with the ResetSeqNum > flag. > This can result in loss of messages if you are not careful. > > --oren > > ----- Original Message ----- > From: "Francis Gingras" <fr...@at...> > To: <qui...@li...> > Sent: Wednesday, June 15, 2005 7:35 PM > Subject: [Quickfix-developers] RE: Logout reason > > > > 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 > > > > Oren, > > > > You're right QF did send a resend request but the counterparty > closed the > > socket so I didn't notice. (see log below) > > > > The "sequence number too high" message is from the client > (initiator) > > point > > of view. It appears that the counterparty does not send a logoff > or a > > session rejection message; it just closes the socket when it > receives a > > MsgSeqNum that is lower than what it expects. BTW it's not a QF > acceptor > > but a custom 3rd party server. > > > > This is why the only solution I see is to increase the > > setNextSenderMsgSeqNum by 1000 every time the socket drops during > logon, > > but > > I'm not comfortable with such a kludge; what if there are other > conditions > > that cause the socket to drop? Comments welcome. > > > > So to conclude, it does not appear to be a QF issue after all > because the > > acceptor side does not send any notification that the logon failed. > > > > 20050613-20:26:19 : Created session > > 20050613-20:26:19 : Connecting to 127.0.0.1 on port 10501 > > 20050613-20:26:19 : Connection succeeded > > 20050613-20:26:19 : Initiated logon request > > 20050613-20:26:19 : Received logon response > > 20050613-20:26:19 : MsgSeqNum too high, expecting 1 but received > 481 > > 20050613-20:26:19 : Socket Error: Connection reset by peer. > > 20050613-20:26:19 : Disconnecting > > 20050613-20:26:19 : Sent ResendRequest FROM: 1 TO: 0 > > > > Thanks, > > > > Francis > > > > > > > > > > ------------------------------------------------------- > > 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 > > > > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- 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: Joerg T. <Joe...@ma...> - 2005-06-16 22:20:04
|
Oren Miller wrote: > I've found your patch from your earlier posting. It just slipped > through the cracks. I'll get it in. Usually if you want to make sure > that something doesn't slip through it's best to add it to the > bugtracker: http://www.quickfixengine.org/bugtracker/ In addition, it would be very good to have such a "what"-argument in the Session.logout() method. Since logout() just sets the member variable m_enabled to false, the logout reason has to be provided in some other member, ie m_logout_reason? What do you think, Oren? > I added an issue for this to make sure it won't slip again: > http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=80&pos= http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=82 Cheers, Jörg -- Joerg Thoennes http://macd.com Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen |
