|
FAST Protocol
< Previous Next >
Re: FAST over TCP
Hei Chan / N/A
11 Jan 2010 5:20AM ET 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!
Re: FAST over TCP
Hei Chan / N/A 11 Jan 2010 5:20AM ET
|
