Imported from previous forum
Should a FIX Message Parser always ignore 34=# on an inbound LonOn message?
For example, the parser is expecting the next inbound MsgSeqNum to be 80 <34=80> and it is not expected that the next message would be a Logon Message <35=A>. However, the next inbound message is a Logon message, and its MsgSeqNum is lower than expected, say 78.
Now in this case, should the parser acknowledge the LogOn and then do a PossDup/PossResend analysis or should it ignore the LogOn altogether and send a ResendRequest.
First point - Message Sequence number (34) should never be ignored. Its the FIXField which permits FIX sessions to recover after TCP disconnect and FIX requires Ordered message processing.
Note :- All quotes in this FIX message are from FIX_Transport_1.1.pdf (March 2008)
I see multiple cases
Case 1) There is a second connection attempt i.e. a new inbound TCP client socket connection is received by the TCP server socket listener
Topic “When to send a Logout vs. when to just disconnect” page 37 / 66
If during a Logon one receives a second connection attempt while a valid FIX session is already underway for that same SenderCompID, it is recommended that the session acceptor immediately terminate the second connection attempt and not send a Logout message. Sending a Logout message runs the risk of interfering with and possibly adversely affecting the current active FIX connection. For example, in some FIX system implementations, sending a Logout message might consume a sequence number that would cause an out of sequence condition for the established FIX session.
Case 2) 24 hour connectivity
Topic “Session protocol” page 8 / 66
It is recommended that a new FIX session be established once within each 24 hour period. It is possible to maintain 24 hour connectivity and establish a new set of sequence numbers by sending a Logon message with the ResetSeqNumFlag set.
In this case 34=1
Case 3)There is a brief disconnect followed by reconnect.
In this case Logon would be the first message received.
Topic “Message Recovery” page 12 / 66
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.
…
The administrative messages which are not to be resent are: Logon,…
So for a Logon message there is no PossDup /PossResend processing to be done. That leaves us with disconnection and manual intervention as the recommended course of action.
Case 4) FIX Session is stable i.e. there is no disconnect and its not 24 hour connectivity and the next message is Logon.
Topic “Reject (session-level)” page 25 / 66
The reject message should be issued when a message is received but cannot be properly processed due to a session-level rule violation.
…
Generation and receipt of a Reject message indicates a serious error that may be the result of faulty logic in either the sending or receiving application.
Conclusion
Since your post is a low sequence number case, i think case 3) is applicable
Should a FIX Message Parser always ignore 34=# on an inbound
LonOn message?For example, the parser is expecting the next inbound MsgSeqNum to be 80
<34=80> and it is not expected that the next message would be a Logon
Message <35=A>. However, the next inbound message is a Logon message,
and its MsgSeqNum is lower than expected, say 78.Now in this case, should the parser acknowledge the LogOn and then do a
PossDup/PossResend analysis or should it ignore the LogOn altogether and
send a ResendRequest.
Thank you so much for the detailed reply. It was case number 3. A wire went off the hook somewhere which caused this.