BFlat Messages

The BFlat message format combines the simplicity and efficiency of simple, schemaless data formats such as FIX and NVFIX with the ability to manage binary data and preserve the full precision of numeric values. BFlat is especially useful for applications that deal with binary data or precise numeric values while demanding high levels of throughput.

A BFlat message is composed of any number of tag/value pairs, similar to FIX and NVFIX messages. Tags and values can contain any value and can be of any length. Unlike formats such as FIX, there are no reserved characters. In practical terms, the name of a tag must be a valid XPath identifier to filter the message in AMPS. However, this is a limitation of XPath and not of the BFlat message format.

The BFlat message type supports all AMPS features and there are no special considerations when using the BFlat message type.

Open-source libraries for producing and parsing BFlat messages are available from the BFlat project site.

BFlat Data Types

BFlat messages are strongly typed. For numeric values, BFlat can preserve the precise value of the following numeric types:

Type	Description
int8	8-bit integer
int16	16-bit integer
int32	32-bit integer
int64	64-bit integer
double	64-bit IEEE 754 floating point number
datetime	UTC datetime containing milliseconds since Unix epoch (64-bit representation)
leb128	Signed LEB128 integer (variable length)

BFlat also includes the following non-numeric types:

Type	Description
null	Empty field
string	String of bytes BFlat does not specify the encoding of a string; this is up to the application to determine.
binary	Untyped sequence of bytes

BFlat includes the ability to represent arrays of values.

Representing Data in BFlat

By convention, BFlat serializers should choose the most compact representation of a given value. For example, if an integer value can fit into 8 bits, it should be serialized as a value of type int8. An application that parses BFlat should assume that a serializer may use different types for values in the same field, to optimize for a compact representation, and should not rely on a value being of a specific type.

For example, a TotalValue field that can have any integer value could be serialized with a type of int8 for values that fit in 8 bits, but could be serialized with a integer type that includes more bits if the value is larger, and could be serialized with the leb128 type for integer values that cannot be represented in 64 bits.

When the AMPS server must serialize a BFlat message (for example, when projecting a view or as a result of enrichment), AMPS tries to optimize for the most compact message size, which could change the representation if the serializer did not choose the most compact type for a value.