[This message was posted by shwetang shah of siac <[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/aa1f62c3 - PLEASE DO
NOT REPLY BY MAIL.]
> 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
[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
-~----------~----~----~----~------~----~------~--~---
