|
FAST Protocol
< Previous Next >
Re: FAST over TCP
Rolf Andersson / Pantor Engineering
11 Jan 2010 1:13AM ETHi,
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
Rolf Andersson / Pantor Engineering 11 Jan 2010 1:13AM ET
|
