[Quickfixj-users] What is right behaviour when counterparty ignores ResetSeqNumFlag?

[Toli K. <to...@ma...>]

Hi all,

I have a scenario where my FIX counterparty ignores the sequence
number reset request in my logon message: when i send the
ResetSeqNumFlag, the Logon message coming back does not contain the
reset field, and QF/J gets confused (see fuller discussion below).

I wonder what the right behaviour is. I don't think the FIX protocol
specifies it.

Here are the details for the transaction:

    OMS (mine)          FIX-broker  (counterparty)
1)  Logon (141=Y) --->
2)                <---  Logon
3)  Logon         --->
4)                <---  Logon

Where 141 is field ResetSeqNumFlag.  After 4, QuickFIX is throwing an exception.

We send the logon message with ResetSeqNumFlag, counterparty replies
with regular Logon message w/out the flag.
Our side of QFJ expects a Logon message in return that also has
ResetSeqNumFlag set to 'Y', but receives a logon request without
ResetSeqNumFlag in it (message 2).  At this point the counterparty
believes the logon handshake is done.  Our OMS however treats message
2 as a new logon request and replies with a logon response (message 3,
which according to the FIX protocol is syntactically identical to a
new logon request).  The OMS now believes the Logon handshake is
complete. The counterparty replies to what it sees as a logon request
(message 3) with another logon response (message 4).

At this point QF/J on our side believes to be in an inconsistent logon
state and quits with (quickfix.SessionException>  Logon state is not
valid for message (MsgType=A))

Looking through the code in quickfix.Session i can see where the 2nd
logon from our side (message 3) is generated. It's in the
Session.nextLogon() method (line 1305 in the HEAD)
        if (!state.isInitiator() || (state.isResetSent() &&
!state.isResetReceived())) {
            getLog().onEvent("Received logon request");
            generateLogon(logon);
            getLog().onEvent("Responding to logon request");
        } else {
            getLog().onEvent("Received logon response");


Since the counterparty doesn't send the ResetSeqNumFlag, we end up
inside the if case and think that someone is trying to connect to us,
generate a logon and that's how it all falls apart.

Any  thoughts on what the right behavior should be? From our side, we
can disable auto-sequence-number reset and figure out some other way
to handle that.

However, the underlying ambiguity is in QF/J and not application code.
It's the same behaviour in the C++ QF code too

Any thoughts?

thanks!

-- 
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.