Re: [Quickfix-developers] RE: Logout reason

[Brian E. <azz...@ya...>]

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
>