Sequence reset on logon

[TomasVetrovsky]

Part of code has been lost from the C++ version of QuickFix in the Session.NextLogon function. The missing part should handle ResetSeqNumFlag(141) in the received logon message. I am not able to force resynchronization of communication as it was possible with the C++ version of the engine. The missing part goes:

if (state_.ReceivedReset)
{
    this.Log.OnEvent("Logon contains ResetSeqNumFlag=Y, reseting sequence numbers to 1");
    if (!state_.SentReset)
        state_.Reset();
}

It also seems that .Net version is very strict in response to Logon with sequence reset. When I added the code above to overcome "Sequence to low" disconnection, the .Net version of engine responds with logon message with sequence reset flag on. It is handled with the code in GenerateLogon:

if (state_.ReceivedReset)
    logon.SetField(new Fields.ResetSeqNumFlag(true));

IMHO this behaviour is not needed. As both sides already reset the sequence numbers when they processed the first logon message.

Test (A=Acceptor, I=Initiator):

1. Start communication in a common way. Send some messages to achieve both sequence numbers higher values.
2. Disconnect
3. I - reset session (set seq numbers to zero)
4. I - try connect with ResetSeqNumFlag=Y
5. A - disconnects with "sequence too low" - should connect with reset sequence numbers.

[gbirchmeier]

To summarize, are you just saying that QF is not handling 141 correctly?

We do have an AcceptanceTest to verify this behavior:
quickfixn\AcceptanceTest\definitions\server\fix44\SessionReset.def
(Lines that start with "I" are tester->QFapp. Lines that start "E" are QFapp->tester.)

Is your scenario different than the test?

[TomasVetrovsky]

First problem is that acceptor does not handle correctly received Logon message with ResetSeqNumFlag=Y. This bug was reported here too:
http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/2012q2/000170.html

Second part of my comment is about ResetSeqNumFlag (In response Logon message to a Logon message that contains ResetSeqNumFlag=Y). The behaviour adheres to the acceptance test. I have gone through the FIX specifiacation (fix-44_VOL-2_w_Errata_20030618.pdf) and have not found any information how this should work. So, It is only my opinion that the ResetSeqNumFlag should not be set in the response Logon message. FIXimate says:
141 - Indicates that the both sides of the FIX session should reset sequence numbers.

[gbirchmeier]

From chats with @mgatny on Nov 19/20:

First part:

His first point seems to be correct: that QF/n is missing a bit of reset logic as compared to QF/c++. I see it in the c++ source but not in QF/n.

Missing a FIX requirement. Seems we're missing a test in that case.

Second part:

His second point I could not immediately verify by comparing the source. He seems to be saying that if seqnums are greater than 1, then you disconnect, then you reconnect with ResetOnLogon=Y, the Acceptor does not honor it. Instead, it complains that the initiator seq nums are too low. We could quickly verify this by testing with the QF/n executor and the QF/c++ executor side by side.

[TomasVetrovsky]

code in TomasVetrovsky@0344291

[KorkyPlunger]

We are also having this issue in the wild with live clients, and independently arrived at the same fix that TomasVetrovsky suggested.

[gbirchmeier]

Thanks, @KorkyPlunger. Will prioritize for next release.

[gbirchmeier]

The first bug in the initial report (disconnect when 141=Y received after disconnect) was fixed by PR #256 and has been in master for more than a year now. I just wrote and merged a new acceptance test to verify this bug and the fix.

I'm working on tests/fix for the second bug (141=Y should not be in the Acceptor's login response) right now.