CODEWITHSUNDEEP
quickfixfix-protocol
user2169513
user2169513

Reputation: 222

FIX protocol: Should out-of-sequence Logout messages due to an error consume a sequence number on the receiver side?

We have long-running FIX session that runs almost 24/7. Due to a misconfiguration it happened that our initiator peer used local time for the session start & end vs. UTC on the other's acceptor peer, so the initiator started a new session 1h before the former session was reset on the other side.

The result was 1h of logon attempts refused with "MsgSeqNum too low" (unquestionable) until the reset on the other side. After the reset on the acceptor side their sequence number started with 1 (as expected) but now their logon responses got rejected from our side, again with "MsgSeqNum too low" until the sequence number of their logon responses catched up again with our expectation.

It seems like an out-of-sequence Logon message does not consume a sequence number on the receiver while such a Logout message does. A code review in the underlying QuickFix engine (the C++ one) confirmed this behaviour. The "FIX Session Layer" documentation also contains a lot of information about sequence numbers and connection termination but doesn't seem to cover this behaviour (at least I didn't find an answer there).

For sure it makes sense to accept Logout messages without insisting on the sequence number, but should they be counted (consume the next sequence number; on the receiver) if they are out of sequence? Is the observed behaviour expected and defined somewhere?

Upvotes: 1

Views: 42

Answers (1)

Christoph John
Christoph John

Reputation: 3283

I also stumbled over this problem some time ago. The thing is that the FIX specification itself does not mention the concept of session times. That concept was introduced by QuickFIX as far as I can tell.

So in my opinion the observed behaviour is expected at least for QuickFIX. I don't know how other FIX engines handle this, though.

Upvotes: 1

Related Questions