[This message was posted by Dale Wilson of Object Computing, Inc 
<[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/0d9cb044 - PLEASE DO NOT REPLY BY MAIL.]

Sean on the 'FAST Protocol' forum at fixprotocol.org wrote:
>
> Has anyone had any experience decoding the FAST multicast market data 
> from ArcaBook?

Hi Sean,

I have built ArcaBook support on top of QuickFAST -- the open source 
implementation of FAST that I maintain.

   http://quickfast.googlecode.com  

I must qualify this by saying that the ArcaBook-specific code won't go into the 
open source repository in it's current form -- it's too dependent on the system 
of the particular customer for which I did  the work. 

> I'm attempting to use the decoder they provide in the DevPak (and 
> they insist works on their discussion forums) with sample data I 
> downloaded from them, as well as some sample messages I found posted 
> on their forums but am not having much luck.

Yes, the sample decoder and sample data were pretty much useless.  It wasn't 
until I started decoding the live data stream that I figured out what they were 
trying to say in the ArcaBook Multicast spec documentation. 

> If anyone has done this, and has any other sample data or 
> knowledge/experience to pass along I would be very grateful.
> 
I can't provide sample data without a consulting contract, however what I 
learned about ArcaBook includes:

    * The compressed ArcaBook data  is best described as FAST-like.  It differs 
from the FAST specification in several ways.   To be fair, I believe Arca came 
first -- they were compressing their feed before the FAST spec existed.

    * An ArcaBook packet has an uncompressed header.   Within that header is a 
MsgType.  By examining the MsgType you can determine whether the remainder of 
the packet is compressed -- some are, some are not. 

    * If it is compressed, the remainder of the packet is a sequence of 
compressed messages.  NumBodyEntries tells you how many. You also have to 
examine MsgType to determine the size of the uncompressed header so you can 
find the start of the compressed body entries.

    * From the table in Appendix C of the ArcaBook Multicast spec you can 
determine which fields exist in each message type, however, they do not 
necessarily appear in the order in which they are given in the table.   They 
appear in the order in which they would have appeared in the uncompressed 
message (more or less.)

    * The presence map bit assigned to each field is hard coded.  As a result 
of this and the previous bullet point, the presence map bits are not consumed 
in order the way they are in a normal FAST message.

    * ArcaBook includes some additional field types which are not in the FAST 
specification. On the other hand, the ArcaBook data does not contain groups, 
sequences, decimals, or ByteVector data which greatly simplifies matters.

I hope this helps gets you started.  

Dale Wilson
Principal Software Engineer
Object Computing, Inc. (www.ociweb.com)


[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
-~----------~----~----~----~------~----~------~--~---

Reply via email to