Re: OPRA is not FAST
shwetang shah / siac
7 Nov 2008 3:03PM ET
> Oleg, As far as I can recall, there are several points where the feed is
> not FAST compliant.
>
> 1. It includes a proprietary header and I believe a footer on each
> message. This would not be the end of the world if the payload was
> actually compliant.
>
> 2. The biggest issue is the Quote template. The quote template
> definition is not constant, it is defined after you process the BBO
> appendage fid, and based on the value, you can then determine the
> number of fields that follow. This could be solved by having a
> template ID for each possible BBO appendage.
>
> This one was my own creation in the early FAST proof of concept days,
> that is how I coded it to show haw FAST could work on Opra data. It made
> sense at the time, but that was before FAST was formalized.
>
>
> Look at the supplied fast_decode.c from Opra, and search for:
>
> //decode bbo indicator msg->bboIndicator = fast->decode_u32(fast,
> BBO_INDICATOR);
>
> switch(msg->bboIndicator) {
>
> This explains it all (if you read 'C' code). The value of BBO_INDICATOR
> determines the number and type of fields that follow, this is not FAST
> compliant.
>
> I do believe Rolf and some other members of the group are performing a
> more complete survey of the Opra implementation.
>
> /Daniel
For the point # 1.
As far as I understood the specification of FAST1.1, proprietary header and trailer is completely independent of the compliance. This is application specific and does not play any role for the FAST (like UDP packet header has nothing to do with FAST). More over the greatest advantage of the packet header is for the network group who wants to check the sequence of the messages without decoding the FAST messages. This header give flexibility and information about the sequence number of the 1st message and the number of messages/packet, size of the message etc. This information will be vary valuable for the tools like Sniffer where without integrating FAST protocol to tools network engineer can analyze the gaps in the packets. Actually FAST working group should consider this idea for the future.
For the point # 2.
OPRA consist of generalize template for all the messages. FAST engine can (must) run without any business knowledge of the message and strictly based on the information received from the wire. So if the FAST 1.1 compliant decoder is placed with these messages, it should work. Later application needs to build the state engine to constitute the message based on the information received from the FAST engine(decoder/template).
Sample decoder is given as an example and to reconstitute the original message to ASCII. State machine is being used to decode the original message.
Now going back to the original comments about the compliance. OPRA uses only two different type of operators.
1. Copy : There is no change from FAST 1.0 to FAT 1.1 spec. So this operator for 1.0 is comply with 1.1
2. increment : There is no change from FAST 1.0 to FAT 1.1 spec. So this operator for 1.0 is comply with 1.1
So if the reference for adding more template IDs for bbo indicator then it is incorrect as per the spec as it will make FAST engine from generalize engine to OPRA specific.
I am still looking in the section 10.0 of FAST 1.1 where there are some ambiguity which needs to be resolve. For example, the xml statement doesn’t mandate to have the templateIdentifier as the 1st bit of the presence map.
message ::= segment
segment ::= PresenceMap TemplateIdentifier? (field | segment)*
and the other statement where TID is optional as the 1st bit.:
“A segment has a header consisting of a Presence Map followed by an optional Template Identifier. The segment has a template identifier either if it is a message segment, or if the segment appears as the result of a dynamic template reference instruction. A template identifier is encoded as if a copy operator was specified. The operator uses the global dictionary and has an internal key common to all template identifier fields. This means that a segment with a template identifier does not always contain the template identifier physically. However, the first bit in the presence map is allocated by its copy operator. “
Please let me know if I am misinterpreting the spec.
-Shwetang
@FIXProtocol
