[This message was posted by Rolf Andersson of Pantor Engineering <[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/d404b924 - PLEASE DO NOT REPLY BY MAIL.]
Hi Janaka, I confused the issue by using the (incorrect) "frame length" instead of "block length". As can be discerned from the grammar description in section 10, a stream is either composed of zero or more messages _or_ zero or more blocks. A block is composed of a block size and one or more messages. The communicating parties have to agree off-line on whether they want to use blocks or not. Blocks can be seen as an encapsulation of one or more messages. The use of blocks is optional. Please exchange frame length below for blocks. I don't know of anyone that currently uses blocks. Sorry for the confusion, thanks for commenting. Best, Rolf > But please see FAST 1x1: 10 - Transfer Encoding section. It say > that it is not a optional field. <i>(FAST 1x1: 10 - Transfer > Encoding - A block is a sequence of one or more messages. A > block has a leading block size specifying the number of bytes > occupied by the messages of the block. It is a dynamic error > [ERR D12] if a block has zero size. The block size is > represented as an Unsigned Integer which may be overlong. > The overlong property is defined in the Integer Numbers section > below)</i> > > > Thanks for your quick reply! > > > > > Hi, > > > > > > Frame length is a feature that must be agreed on bi-laterally. There > > > is nothing in the wire data that tells you it is there and it is > > > currently not used in any impl as far as I know. > > > > > > Frame length is optional and it was included in the std to simplify > > > parsing for those who wanted to build a more naive FAST decoder over > > > TCP. Depending on how you implement your decoder you may or may not > > > have use for a frame length. A side-effect of using the frame length > > > construct is that you can skip over a message that you don't > > > recognize. > > > > > > This is not without complications as you must make sure that the > > > previous value state for your field encoding operations remain > > > intact. So, even if you don't know how to decode the message you > > > have to know that there are no dependencies to messages that you do > > > know and therefore can parse. > > > > > > The rules and best practices around frame length are still somewhat > > > untested, so proceed with caution. > > > > > > I recommend that you don't use frame length unless you believe you > > > have a strong reason to use it. > > > > > > HTH, Rolf > > > > > > > Hi, > > > > > > > > I read http://www.fixprotocol.org/documents/2301/A%20Basic%20Guide%20to- > > > > %20FAST%20v1.0.pdf. > > > > > > > > I am confused about the frame length field mentioned on page 17. > > > > > > > > I am sending an encoded message over TCP (socket). So do I need to > > > > prefix the message with the length of the message? > > > > > > > > If yes, how does the receiver know that it is a new message (given > > > > that date transferred over TCP is just a byte stream)? > > > > > > > > If it has been asked, please give me a pointer. (A little bit hard > > > > to use the search function here...:() > > > > > > > > Thanks in advance! [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.
