|
FAST Protocol
< Previous Next >
Re: FAST over TCP
Rolf Andersson / Pantor Engineering
11 Jan 2010 6:30AM ET 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. (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)
>
> > 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
Rolf Andersson / Pantor Engineering 11 Jan 2010 6:30AM ET
|
