PUBLIC COMMENT PERIOD - Simple Binary Encoding specification Release Candidate 3

, , ,
1

Imported from previous forum

2

This proposal from the High Performance Working Group entails the use of a FIX Trading Community designed Simple Binary Encoding (SBE) to produce fast and compact encodings of FIX messages. SBE provides different characteristics than other binary encodings. It is optimized for low latency.

This new FIX binary encoding complements the existing only binary encoding developed in 2005 (FAST) which had a focus on reducing bandwidth utilization for market data. In addition, the encoding is also defined and controlled within the FIX Trading Community, in contrast to the binary encodings proposals to encode FIX with Google Protocol Buffers and ASN.1.

The third release candidate documents for SBE can be found here.

The proposed technical standard for Simple Binary Encoding of FIX is following the technical standards review process described in the document found here.

This third release candidate now enters a public comment period in which public review and feedback is encouraged. The public comment period will run for a period of 90 days beginning on Monday the 22nd of December, 2014.

Please post feedback, comments, and questions as replies to this discussion thread.

3

Hi,

How is it recommended to specify FIX Components in SBE? It seems like the composite type is the closest there is. However, it does not seem to perfectly align since a composite is only composed of types, not fields(since fields have an equivalent FIX id while types do not).

Please advise.

thanks,
Luke

4

One addition to the question above. It seems as if composites can only declare new encodings, in other words, you cannot reference an already defined enum, type, composite, or set. This seems rather limiting as well. It would be nice if it could do this.

5

Luke,

A composite encoding backs a single FIX field. The classic example is MonthYear data type that consists of parts for year, month, day, and week. Composite type was not intended for component block definitions, groups of fields that are shared among messages.

SBE does not currently have an equivalent of a component block. Messages must be fully exploded.

There are at least two ways to do deal with it now without having an explicit feature in SBE:

  • XML include of a fragment into the main XML document could be used to pull in common encodings. This was the rationale for allowing multiple “types” elements in a message schema.

  • Tooling or XML transforms could compose a message by exploding externally sourced snippets.

Common field blocks could be defined as a future SBE enhancement if there is a consensus to add it.

6

Thanks.

Understood about the composites, that makes sense. I think a Component element would be useful. They are already conceptualized in FIX and having them is nicer than creating bespoke tooling, especially if you need to deliver SBE XML to thirdparties, as it makes the commonality between messages much clearer.

Also, has there been any thought about union types? This would be helpful for more dynamic fields such as NoStrategyParameters, so that it would be possible to encode as the actual type instead of encoding as a string and then converting (or actually implementing a union type on top of SBE).

7

Luke, thanks for your proposals. I will raise them with the High Performance Working Group for consideration.

Components would be relatively easy to add to the SBE XML schema since there is already an XML type that could serve the purpose called “blockType”.

I have reservations about the possible complexity of unions. You are right that StrategyParametersGrp acts as a discriminated union. Do forum readers foresee other use cases for this?