[This message was posted by janaka Sooriyaarachchi of MillenniumIT <[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/b00bfc40 - PLEASE DO NOT REPLY BY MAIL.]
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.
