[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/dd89eeaf - PLEASE DO NOT REPLY BY MAIL.]
> 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 -~----------~----~----~----~------~----~------~--~---
