Imported from previous forum
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!
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!
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!
[ original email was from janaka Sooriyaarachchi - janakas@millenniumit.com ]
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!
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!
[ original email was from Mikael Brannstrom - mikael.brannstrom@ngm.se ]
> The use of blocks is optional. Please exchange frame length below for
blocks. I don’t know of anyone that currently uses blocks.
FYI, NGM (Nordic Growth Market) uses blocks, an overlong 4 byte BlockSize with one message per block.
/Mikael
Mikael, I should have remembered that.
Apologies,
Rolf
The use of blocks is optional. Please exchange frame length below for
blocks. I don’t know of anyone that currently uses blocks.FYI, NGM (Nordic Growth Market) uses blocks, an overlong 4 byte
BlockSize with one message per block./Mikael