[This message was posted by Mahesh Kumaraguru of <[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/f65707e7 - PLEASE DO NOT REPLY BY MAIL.]
Thanks Ryan for clarifying, I meant only Application Version Independence and I was refering only to a TCP FIX engine. I agree that if there is a fully running FIX.4.4 engine, its easy to modify it to support FIXT.1.1 without support for Application version independence. While running a FIXT.1.1 session how can I choose to not implement Application version independence ? Have bilateral agreement with counterparties by saying my FIXT.1.1 session would not support ApplVerID(1128), CstmApplVerID(1129), RefApplVerID(1130), RefCstmApplVerID(1131) and DefaultCstmApplVerID(1408), also accept DefaultApplVerID(1137) in the Logon message with the only Application version that shall be supported? I have come across many FIX learners and most of them found the ascend from FIX.4.0 upwards easier than starting with FIX.5.0 since FIX.4.0 is Equities centric (http://www.fixprotocol.org/functionality) with practically no support for other asset classes. A FIX engine can do stateless validation using the Repository. Am I right in stating the action that needs to be taken on receipt of a particular message has to be coded in the application and cannot be derived from repository? For example if a valid New Order single is received, whether to reject it or ack it followed by multiple partial fills to fully fill it or send a full fill or ack it and no fills till TimeInForce expiry etc has to be in the application code and depends on state of market? For developers starting their journey into the FIX world, its easier to deal with the relatively smaller number of application messages and tags. If a number of pages comparision between FIX versions is incorrect, would a comparision of number of messages and/or tags be more appropriate? Since Shahbaz stated he is fairly new to FIX wire level protocol and wanted to implement a "simple" FIX engine as a learning excercise, I suggested that he start with FIX.4.0. A beginner in Java would start with a HelloWorld.java (print a String to console), then keep going up in complexity, a beginner would not start as his first program a Sun Certified Java Developer level client-server application ( http://www.sun.com/training/catalog/courses/CX-310-252A.xml ). When I started writing my first TCP FIX engine (like Shahbaz I wrote both the FIX Client and FIX Server) taking the TCP Sockets client server example given in the Sun Java tutorial at http://java.sun.com/docs/books/tutorial/networking/sockets/index.html, the Server would start listening on a predefined port and the client would open a TCP socket connection to this port and send the String 8=FIX.4.0^, the Server would accept the inbound socket and if the String it receives is 8=FIX.*.*^ the server will start a new Th read and this Thread will write back the same String to client else the Server would close the socket. Then this program kept going up in incremental steps towards full production grade FIX test Broker ( http://www.geocities.com/kay_mahesh/Mahesh_Polaris_FIX_Excellence_award.jpg ) which is used for QA testing real FIX trading applications (LatentZero Minerva+Cameron, CRD+Cameron, XIP+MET). Shahbaz, I am not trying to sell you some old rotten stuff which stinks, btw "Money stinks". I am just showing you the path which I followed. > > I am not sure if starting with FIX.5.0 is the right idea because > > FIX.5.0 runs on top of FIXT.1.1 which would require you to implement > > "Transport Independence" i.e. multiple FIX application versions in a > > single session whereas FIX.4.0 upto 4.4 do not have this advanced > > concept. So a FIX.4.0 engine would be much simpler than a FIXT.1.1 > > engine. FIX.4.0 specs is a single document of 87 pages whereas FIX.5.0 > > specs is 7 volumes + one document of FIXT.1.1 > > Mahesh is correct in that all of the FIX 5.0 versions run on top of > FIXT.1.1. And he is correct that Transport Independence is included > in FIXT.1.1. > > However, I strongly disagree with Mahesh's assertion that one must > support Transport Independence to support FIXT.1.1. > > First, I need to draw a distinction in terms. I think he is referring to > Application Version Independence, which often gets bundled under > Transport Independence, and it is helpful to consider them separately. > > Transport Independence is the de-coupling of the FIX session and > application layer. It allows a person to send a FIX message over a non- > FIX transport, like Tibco, MQSeries, Web Services, etc. But the issue at > hand here is building a FIX engine, so this isn't relevant. > > FIXT.1.1 also supports Application Version Independence, which means > allowing a FIX session to run multiple versions of FIX application > messages over the same FIX session. > > Just because FIXT.1.1 supports Application Version Independence doesn't > mean your FIX engine must support it! The vast majority of people use a > FIX session for one version only. Provided you don't want to support > Application Version Independence, the differences between the FIX 4.4 > session and FIXT.1.1 are trivial. FIXT.1.1 uses a different BeginString. > The Logon message adds a required tag called DefaultApplVerID. That is > where you specify the FIX version of application messages. I believe > FIXT.1.1 also specifies the order of certain header fields. But that's > about it. A good programmer with a FIX engine supporting the 4.4 session > who is familiar with its source code can probably modify it to support > FIXT.1.1 (without Transport Independence) in a couple hours of coding. > > Again, I must strongly reiterate: FIX 5.0 is not difficult to implement! > FIXT.1.1 (provided you don't need Application Version Independence) is > not difficult to implement! > > FIX 5.0, 5.0SP1 and 5.0SP2 all use the same session: FIXT.1.1. The only > thing that really changes at the session layer is that we have to add a > new enumeration to DefaultApplVerID with each new service pack release. > An engine that supports 5.0 can trivially support 5.0SP1 and 5.0SP2. The > differences lie at the application level, not the session. > > If the engine validates application-level fields (and not all do, nor > need to), that can be accomplished via the Repository, which is an XML > machine-readable representation of the protocol, provided by FPL. So > supporting validation for a new Service Pack means importing a new > Repository. > > Mahesh's assertion of complexity by comparing 87 pages to 8 volumes is > like comparing apples to oranges. Almost all of the enhancements made to > FIX since 4.0, which account for the vast increase in page count, are at > the application level, not the session level. The session level has > largely remained unchanged over the past 12 years. Other than the > changes to FIXT.1.1, I need to point out that FIX 4.0 and 4.1 used > EndSeqNo=999999 in Resend Requests to denote infinity (effectively > preventing a FIX session from handling more than a million messages a > day), while FIX 4.2 onward use EndSeqNo=0 and eliminate the restriction. > > Writing a FIX engine is a good challenge. It becomes much more difficult > if one needs to make it ready for production use, which usually requires > fault tolerance as well as a lot of performance tuning. But differences > between FIX versions themselves are, to an engine, negligible by > comparison. I suspect the decision to support one FIX version vs. all of > them is going to be negligible in terms of engine development time. [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 -~----------~----~----~----~------~----~------~--~---
