[This message was posted by Ryan Pierce (FPL Technical Director) of FIX Protocol Ltd. <[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/b14ce8da - PLEASE DO NOT REPLY BY MAIL.]
While I believe in following the spec closely, I'm also a big fan of defensive coding in FIX engines, much like defensive driving. (This is very important for me, living in Chicago where turn signals are considered novelty items. ;-) In my mind, an engine that cannot tolerate slightly non-standard behavior is overly fragile. In your examples: > 1. > > Seq1 A -----> B (Logon with 141=Y) > Seq1 B -----> A (Logon Acknowledgment without 141=Y) > Seq2 A -----> B (Logon message again with 141=Y) Yes, B should have sent 141=Y. But A has just received, in response, a Logon with Seq1. It should be clear, even though 141=Y isn't set, that a session was established and the sequence numbers were reset. There is no reason A should send a second Logon. And things go down hill from there. > 2. > > Seq1 A -----> B (Logon with 141=Y) > Seq1 B -----> A (Logon Acknowledgment without 141=Y) > Seq1 A -----> B (TestRequest) B now throws an error as it > has received the second message with the same SeqNum 1 as Logon and > disconnects. Again, A has received a Logon with Seq1, admittedly without 141=Y. It should be obvious to A that a successful Logon has occurred at this point. But A responds by reusing Seq1! This is blatantly non-standard, and really isn't recoverable; B has no choice but to terminate the session. Yes, you can make an argument that B isn't following the spec by failing to send 141=Y, and B sending 141=Y would fix the problem. But I don't think this error necessarily should be fatal. As long as B's sequence number on its Logon is 1, then it is evident that sequence numbers were successfully reset. I think it would only be a benefit for A to be a little more flexible. Now if B's Logon is not 1, then that indicates sequence numbers were not reset, and this is an entirely different issue. Isn't QuickFIX/J (which I assume is A in this example) open source? How hard would it be to make a small code change to infer 141=Y on B's Logon if both A's Logon had 141=Y and B's Logon seq number is 1? Wouldn't that fix the problem? [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 -~----------~----~----~----~------~----~------~--~---
