FAST 1,2 technical documentatin

, ,
1

Imported from previous forum

2

Hello!
The question is about new FAST 1.2.
From document (http://www.fixprotocol.org/documents/4372/FAST%201%202%20Extension%20v10.pdf) many things are not clear.

For example it is not clear
(1)
is it any limitation on a number of elements into a set e.g is it allowed to have a set with, says, 100 values(to represent such set 13 bytes is required)?
(2)
which operators are allowed to new types such as set, enum etc?
For example, is it allowed delta to set and how one should interpret this?

Is there any more detailed document which describes how to decode new types?

3

Hi Vitali,

  1. there is no protocol defined limit on the number of elements in a set, but implementations are encouraged to support at least 64 elements (corresponding to a the number of bits in a u64)

  2. FAST 1.2 does not define any operators for the new types. There are a few type/operator combinations that would make sense, but I are currently undefined. This could be an item for either the upcoming version 1.3 or a later version.

Best,
Rolf

Hello!
The question is about new FAST 1.2.
From document (http://www.fixprotocol.org/documents/4372/FAST%201%202%20Extension%20v10.pdf) many things are not clear.

For example it is not clear
(1) is it any limitation on a number of elements into a set e.g is
it allowed to have a set with, says, 100 values(to represent such
set 13 bytes is required)?
(2) > which operators are allowed to new types such as set, enum
etc? For example, is it allowed delta to set and how one should
interpret this?

Is there any more detailed document which describes how to decode
new types?

4

Hi Rolf,

Thank you for the answers.

Could we assume that

  1. enumerations could be decoded just like integers
  2. set and bit group could be decoded just like ASCII strings?

Best,
Vitali

Hi Vitali,

  1. there is no protocol defined limit on the number of elements in a set, but implementations are encouraged to support at least 64 elements (corresponding to a the number of bits in a u64)

  2. FAST 1.2 does not define any operators for the new types. There are a few type/operator combinations that would make sense, but I are currently undefined. This could be an item for either the upcoming version 1.3 or a later version.

Best,
Rolf

Hello!
The question is about new FAST 1.2.
From document (http://www.fixprotocol.org/documents/4372/FAST%201%202%20Extension%20v10.pdf) many things are not clear.

For example it is not clear
(1) is it any limitation on a number of elements into a set e.g is
it allowed to have a set with, says, 100 values(to represent such
set 13 bytes is required)?
(2) > which operators are allowed to new types such as set, enum
etc? For example, is it allowed delta to set and how one should
interpret this?

Is there any more detailed document which describes how to decode
new types?

5

Hi Vitali,

this is obviously an implementation detail:

  1. enums could be viewed as integers
  2. sets and bit groups could be viewed as a vector of 7-bit quantities (reflected by the SBIT-coding). pls bear in mind that fields in a bit group may straddle 7-bit boundaries.

Best,
Rolf

Hi Rolf,

Thank you for the answers.

Could we assume that

  1. enumerations could be decoded just like integers
  2. set and bit group could be decoded just like ASCII strings?

Best,
Vitali

Hi Vitali,

  1. there is no protocol defined limit on the number of elements in a set, but implementations are encouraged to support at least 64 elements (corresponding to a the number of bits in a u64)

  2. FAST 1.2 does not define any operators for the new types. There are a few type/operator combinations that would make sense, but I are currently undefined. This could be an item for either the upcoming version 1.3 or a later version.

Best,
Rolf

6
  1. There is no definition of vector of 7-bit quantities in FAST 1.1.
    So it is unclear what do you refer to.
    Do you mean that each 7-bit element need to be decoded as a separate integer? Or?

Hi Vitali,

this is obviously an implementation detail:

  1. enums could be viewed as integers
  2. sets and bit groups could be viewed as a vector of 7-bit quantities (reflected by the SBIT-coding). pls bear in mind that fields in a bit group may straddle 7-bit boundaries.

Best,
Rolf

Hi Rolf,

Thank you for the answers.

Could we assume that

  1. enumerations could be decoded just like integers
  2. set and bit group could be decoded just like ASCII strings?

Best,
Vitali

Hi Vitali,

  1. there is no protocol defined limit on the number of elements in a set, but implementations are encouraged to support at least 64 elements (corresponding to a the number of bits in a u64)

  2. FAST 1.2 does not define any operators for the new types. There are a few type/operator combinations that would make sense, but I are currently undefined. This could be an item for either the upcoming version 1.3 or a later version.

Best,
Rolf

7

sorry I was a bit terse. my attempt at explaining is not in the spec.
An ASCII string as encoded can be viewed as a vector of 7-bit quantities. You can obviously decode into your representation of choice. With SBIT-coding on the wire, each byte contains 7 data bits and a stop bit. For sets, this can be viewed as a bit vector 7-bits per byte. For bit groups, you may have fields that extend over the boundary of two (or more) 7-bit quantities.

/Rolf

  1. There is no definition of vector of 7-bit quantities in FAST 1.1.
    So it is unclear what do you refer to.
    Do you mean that each 7-bit element need to be decoded as a separate integer? Or?

Hi Vitali,

this is obviously an implementation detail:

  1. enums could be viewed as integers
  2. sets and bit groups could be viewed as a vector of 7-bit quantities (reflected by the SBIT-coding). pls bear in mind that fields in a bit group may straddle 7-bit boundaries.

Best,
Rolf

Hi Rolf,

Thank you for the answers.

Could we assume that

  1. enumerations could be decoded just like integers
  2. set and bit group could be decoded just like ASCII strings?

Best,
Vitali

Hi Vitali,

  1. there is no protocol defined limit on the number of elements in a set, but implementations are encouraged to support at least 64 elements (corresponding to a the number of bits in a u64)

  2. FAST 1.2 does not define any operators for the new types. There are a few type/operator combinations that would make sense, but I are currently undefined. This could be an item for either the upcoming version 1.3 or a later version.

Best,
Rolf

8

Thanks,

Could we assume that operators like delta will work with set and bit group just like with ASCII string?
Is operator tail applicable?

sorry I was a bit terse. my attempt at explaining is not in the spec.
An ASCII string as encoded can be viewed as a vector of 7-bit quantities. You can obviously decode into your representation of choice. With SBIT-coding on the wire, each byte contains 7 data bits and a stop bit. For sets, this can be viewed as a bit vector 7-bits per byte. For bit groups, you may have fields that extend over the boundary of two (or more) 7-bit quantities.

/Rolf

9

no, that assumption is incorrect.
enum, set and bit group are different types.
They just use the same underlying SBIT-encoding as all other existing types except byte vector.

/Rolf

Thanks,

Could we assume that operators like delta will work with set and bit group just like with ASCII string?
Is operator tail applicable?

sorry I was a bit terse. my attempt at explaining is not in the spec.
An ASCII string as encoded can be viewed as a vector of 7-bit quantities. You can obviously decode into your representation of choice. With SBIT-coding on the wire, each byte contains 7 data bits and a stop bit. For sets, this can be viewed as a bit vector 7-bits per byte. For bit groups, you may have fields that extend over the boundary of two (or more) 7-bit quantities.

/Rolf