[This message was posted by Dennis Wiatzka of Nasdaq OMX <dennis.wiat...@nasdaqomx.com> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/b7a67693 - PLEASE DO NOT REPLY BY MAIL.]
> Hi Dennis, > > Could you please clarify your previous statement? > > > This would potentially create enormous redevelopment costs for FIX > > compliant systems. Their implementations are predicated upon this sort of > > thing not being possible. > > Logon with ResetSeqNumFlag=Y is the same as > 1. Logon with MsgSeqNum=MAX_INTEGER, NextExpectedMsgSeqNum=1, followed by > 2. SeqReset-Reset, NewSeqNo=1 > ... but without starting the message retransmission as a consequence of step > 1. > > Steps 1 and 2 are allowed today. In what way would merging these two steps > into one step "create enormous redevelopment costs for FIX compliant > systems"? > > Regards > Mikael Brännström Hi Mikael, I apologise for having to stand against this proposal. In response to your queries... If memory serves, it is not allowed to seqeuence-reset-reset to a number lower than what is next expected. You are only allowed to reset higher. Any session approaching MAX_INT messages over one session likely more urgently needs to split up the traffic over multiple sessions. As regards your previous question re: costs to redevelop and test existing systems. Much of the session state and logic is predicated upon existing data having been committed and applied to the receiving system's state. Sequence numbers never go lower and the session rules guard against that allowing deeper code to safely assume that predicate. Further, the message logs document the contracted commitments of the two parties on either side of the connection allowing for issue resolution. So existing systems would potentially need to be redeveloped, retested and recertified if/when new clients claim that our FIX implementation does not conform to the FIX standard. We have experienced clients & vendors demanding we support this behavior after having seen the 24 hour reset seq num "feature" in the FIX specification. This led to many headaches which too often were abused by vendors and clients, creating potential liabilities for our company. The vast majority of the time connecting parties simply wanted to avoid fixing their bugs or avoid putting into place the required hardware. Ultimately, I would not have any concerns with this proposal if our experiences would have been more positive. Instead, we had nothing but bad experiences with remote connecting vendors and clients using the reset seq num feature as an "out" which then required us to work around their irresponsibility. Where does our liability and responsibility end? It seems that the more appropriate approach to the scenarios this proposal covers is for the session initiator to accept that the bug or hardware failure occured on *its* side and, rather than demanding that the session acceptor reset sequence numbers lower, the session initiator should increase its sequence numbers and notify operators that investigation is required. The session acceptor can include the "next expected seq num" in the logout which rejects the logon. In the case of "the system only stores X messages" then the retrans request should be gap filled up to the point at which the X messages can be resent. Overall, I believe that this is what the FIX protocol presently recommends and such a solution does not impact existing implementations. [You can unsubscribe from this discussion group by sending a message to mailto:unsubscribe+100932...@fixprotocol.org] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to fix-proto...@googlegroups.com. To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
