[This message was posted by Mahesh Kumaraguru of <[email protected]> to the "Certification" discussion forum at http://fixprotocol.org/discuss/9. You can reply to it on-line at http://fixprotocol.org/discuss/read/28ab6914 - PLEASE DO NOT REPLY BY MAIL.]
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. [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
