Re: [Quickfix-developers] RE: Logout reason

[Oren M. <or...@qu...>]

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
>