[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/6b716f92 - PLEASE DO NOT REPLY BY MAIL.]
Hello Hanno, "The alternative for NGM in case of a simple rejection of their proposal is to go away and use custom tags." Respectfully, I must disagree. As noted below, the sessions can resume communications if the session initiator receives the "next expected seq num" in the logout sent by the session acceptor when it receives the logon with seq num less than expected. The session initiator then sends a logon on with seq num set to the value which was sent by the session acceptor. Thus, communications are resumed and the session initiator (the one who had the programmatical or hardware error) is the one who makes the correction. As far as I can tell, this achieves the goals of NGM's proposal though via different means. Contrast this to what is proposed. If the session acceptor is the one who must change when instructed by the session initiator, then they have to either reset their message database or modify their database design to accomodate how messages are indexed. If the database is reset, then how does one resolve issues reported later in the day or days later? Have a second copy of the database and move the messages over? If the messages are simply deleted, we are propogating the failure (loss of messages) from the session initiator's system to the session acceptor's system. What if there are multiple resets during the day? Must the session acceptor be capable of retaining an unlimited number of sets of session messages? If multiple sets of messages are stored in the message database, how is the session acceptor supposed to identify which messages are from before and after the logon with reset when a restrans request is received? If the session acceptor subsequently has a failure and restarts after the session initiator has invoked one or more resets, how is the session acceptor to determine which set of messages it should use to determine what the starting sequence numbers should be? With multiple sets of messages, how much more complex will problem investigation and resolution become? How much will the complexity of certification increase? I acknowledge that all of these challenges can be solved by efforts (costs) on the session acceptor's side. Thus, the proposal by NGM forces all these changes on the side of the session acceptor when the issues the proposal attempts to address are _entirely_ on the side of the session initiator. Yet the solution I suggest is far simpler for both sides of the FIX session and puts the onus upon the system which had the failure. Is this not the way it should be? "System heal thyself"? ;o) Thanks for all your replies and the stimulating discussion. This is the last I will comment on this topic. My opinion remains unchanged - I oppose this proposal and hope it does not become part of the standard. Best regards, Dennis > 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.
