[This message was posted by Clive Browning of Rapid Addition Ltd <[email protected]> to the "FAST Protocol" discussion forum at http://fixprotocol.org/discuss/46. You can reply to it on-line at http://fixprotocol.org/discuss/read/fb4d7cab - PLEASE DO NOT REPLY BY MAIL.]
As Rolf points out the C# reference implementation is based on FAST 1.0 not FAST 1.1 I don't think a reference implementation for FAST 1.1 has been made available to-date although there has been discussion about the benefits of doing so. Regards, Clive > William, > > thank you for taking the time respond. Your points are well-taken. > Please find my comments below. > > There are a number of knowledgeable and helpful forum members. Let us > know if we can be of assistance. Please post your questions and we'll > chip in and respond the best we can. > > Good luck with your implementation. > > Best regards, Rolf > > > 20%... I am saying by not using bit 8 in the stream you have lost 1/8 > > of the data possibly.. Sorry that is 12.5% > > None the less, there is an overhead to enable varying length fields. The > stop bit can be viewed as a length field that is amortized over multiple > bytes. '1'b means 1 byte, '01'b means 2 bytes, etc. In FIX fields are > separated by a byte. We made a decision when designing FAST not to use a > full byte for separation of fields. > > > The Fast Fix documentation and sample code. For example just to > > understand what the message structure is I have on page 44 a few words > > about "Transfer Encoding" with no diagrams etc. > > Agreed. We have discussed complementing the specification with tutorial > documents that describe how to implement and use FAST. As almost all of > the standardization work so far has been on a volunteer basis, we have > yet to get the tutorials written. > > > The translation of FIX into Fast is something else again. > > We have not released a FIX over FAST document yet. It is actually being > written just now by a few volunteers and the FAST 1.2 proposal is partly > a consequence of the need for further specification to support the FIX > FAST encoding. > > > The documents are really really hard to get to grips with. Also the > > sample code is very limited. String Delta operation for example. > > Unless I am missing something you have not bothered with that in the > > c# sample code but it used all the time. > > I don't think you are missing anything. If I recall correctly the C# > implementation is FAST 1.0 and string delta is a 1.1 feature. Clive and > the other guys at Rapid Addition (who wrote the C# refimpl) can respond > more in detail. > > > I used to get EBS LIVE via XML and the code was trivial - literally a > > few days work. I am trying to use their new Fast Fix feed but it's > > really a nighmare. So far it has taken me about a week and I have > > still not logged on properly. > > I haven't been involved in the ICAP EBS FAST feed, but I seem to > remember that they have a few aspects that could be improved. > > That said, I have been involved in using the XML feed and it's verbose > beyond reason. I once did a test where I FAST encoded a 500 MB sample of > the old EBS XML feed into FAST. By using fairly aggressive optimizations > and relying on a TCP transport for the FAST feed (as with the XML feed) > I was able to compress by a factor of over 30. Admittedly, this was in > lab conditions and a lot more testing would be needed, but suffice it to > say, the EBS folks haven't been very aggressive in their encoding. > > > Even when i have done all this I see EBS LIVE sends strings like > > "SPOT.EUR/USD" down the line. It is all a mess. > > Yes, symbology is a generic problem. Strings are much more verbose than > some enumerated/mapped identifier. The FAST 1.2 proposal contains both > enumerations (defined in the template) and maps (defined in the data > stream). We had a long discussion on the mdowg confcall last week where > Greg Maynard of the ISE described how they had solved the symbol > identifier problem in their ISE Depth feed. The ISE feed is one of the > empirical sources together with the CME and Eurex feeds for continued > FAST standardization. > > > What would I do instead? I don't pretend to have an answer to that but > > for EBS LIVE they could have written a much easier format which saved > > a lot of space and was super easy to pass. Using Fast Fix was a > > nighmare and a waste of time unless you own a fast fix engine already. > > > Why bother with mantissa and exponent when all their prices could be > > sent as integer? they have no text data to send just prices so I would > > have had no strings in the messages at all. Why send body length and > > checksums in the fix over fast stuff. Just more work. > > I'll not defend their choices, but they had to decide on this when they > designed the feed without any help from the mdowg, as we hadn't provided > any guidance or best practices at that time. > > I can see their rationale for including these fields, but I agree with > you that it isn't obvious that they should be included. > > > Why send string timestamps when it takes 40us to turn a time to a > > string when you could send an int64 tick time. By trying to do > > everything it just turn into a nightmare and > is slow to boot. > > Indeed, different flavors of timestamps are included in the FAST 1.2 > proposal as a parameterized integer data type. [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 -~----------~----~----~----~------~----~------~--~---
