[This message was posted by Hanno Klein of Deutsche Börse Systems <hanno.kl...@deutsche-boerse.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/43326d3c - PLEASE DO NOT REPLY BY MAIL.]
Dennis, thank you for the feedback which raises an important issue. Apparently, a well intended feature to reset sequence numbers has been mis-used by parts of the FIX community and caused numerous issues for firms like yours. This could very well be caused by ambiguities in the spec that people take advantage of. It could also be an initial lack of understanding and then (after development) looking for something else to blame to avoid the cost of dveloping it as intended by FIX. I therefore see the removal of ambiguities as an alternative to the rejection of extensions to features that are being mis-used today. Clear and official usage guidelines from FPL should help discussions with vendors over such issues. I suggest to focus on the use cases for a reset of sequence numbers, including the ones currently allowed by FIX and the NGM requirements. I hope we can find a way to support all of them without offering loopholes to lazy developers. I see a need to do something regardless of NGM's proposal due to the bad experiences you made in the past. It might mean that we have to extend NGM's proposal to fix existing ambiguities as well. The alternative for NGM in case of a simple rejection of their proposal is to go away and use custom tags. This cannot be in the interest of FPL and I believe we need to put in more effort to solve NGM's business requirements. The current proposal might not be the only way to achieve this but then we need to show another way within the boundaries of the current spec (or with a different kind of extension). Regards, Hanno. > 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.
