Re: Flexibility versus performance
Rolf Andersson / Pantor Engineering
11 Jan 2011 8:25AM ET
Taking a somewhat different perspective, I would argue that we need to _increase_ the flexibility as compared to FIX. This is possible by allowing increased configurability, re-using the good parts of FIX and relaxing some of the current limitations.
To re-iterate some points made in earlier discussions; The current syntax (tag=value encoding) is inflexible in that it doesn't offer more specialized encodings of different application types (string, integer, decimal, ...). A number of fields are superflous in some use cases and would be avoided if they were optional. The FIX recovery mechanism incurs a large overhead in some situations.
By making the HFT protocol more configurable, we will be able to express any FIX message exchange efficiently by allowing bi-lateral agreement of what features, fields, value ranges etc that are relevant for the current use case.
One user's feature is another user's anomaly ..
Best,
Rolf
Hi Georges,
>
> I agree with you regarding preserving the FIX specification because there is a lot of business value into it. One thing I would like to preserve in any HFT protocol design is the flexiblity FIX has to offer. For example, OUCH protocol of NASDAQ is faster but not flexible - the only thing that can be done using OUCH is trade on NASDAQ. But FIX can be used to trade across most geographies of the world on most asset classes using many diverse trading styles. FIX TCP Sessions can transport non FIX data reliably. FIXProtocol is much more than just a trading protocol.
>
> This calls into question our group's choices of flexibility versus performance. My present thought is that when FIX started as Tag=Value^ encoded bytes over TCP/IP, it was flexibility which led to its widespread adoption. Now any changes to FIX which make it faster by reducing flexibility would not be well received by the industry.
>
> For example, if there is a new version of FIX which is faster but cannot accept Tag 58 Text messages longer than 63 bytes, many end users would say "there is no need to upgrade, we want the full tag 58 Text without truncation because our secret Algo parameters are coded in tag 58 text value" or "The text messages are very informative, we want it fully transmitted".
>
> With semantics and business workflows unchanged, if we are able to offer a new HFT encoding to make FIX faster with no loss of flexibility, it could receive wider industry adoption.
>
> Regards,
> K. Mahesh
@FIXProtocol
