[This message was posted by Hanno Klein of Deutsche Börse Systems <[email protected]> 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/a94b1f79 - PLEASE DO NOT REPLY BY MAIL.]
That is good news because it means that NGM can achieve their objective by means of existing FIX capabilities and usage guidelines. That is the better solution but it requires NGM to recognize it. You have provided ample feedback for NGM which will hopefully help to achieve this. My point was that somebody who comes forward with a proposal that is rejected without offering an alternative will not be tempted to think hard about such an alternative but will often take the easy route of custom tags. I was not saying that there is no other alternative for NGM but only that others need to come forward to point to alternatives which is what you have done. The discussion will continue in tomorrow's Global Exchanges and Markets Committee and I hope that we can make some progress for NGM in this matter. > 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 > [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.
