This release is mainly about
Multi-account order routing support
Load-balancing using multiple market data streams
New logging interface
All gateways have been prepared to support multi-account order routing.
All gateways have been upgraded to allow load-balancing of e.g. market data streams.
This feature is useful when market data distribution can’t keep up during busy times thereby causing disconnects.
Previous implementations often used a single connection to subscribe all symbols.
New implementations generally supports a limit on the number of symbols per stream (connection). This means that a number of streams may be established to manage the subscription of all symbols.
The API now supports
stream_idfield is now attached to all updates
StreamStatusupdate message can be received whenever the connection state changes
GatewayStatusupdate message allows you to track the “readiness” of all streams
The API has been upgraded to transparently support multiple data streams from a single gateway. This is a breaking change required to support gateway features such as multi-account order routing and load balancing of market data streams.
The interface has been completely changed and is now fully implemented in C++ (meaning: no longer using pre-processing macros).
The implementation closely follows use cases around
Order Book / Market by Price Changes#
Some exchanges will allow a very large range between minimum and maximum price. This becomes an issue when the following conditions are true
The stream contains incremental updates (to an initial image)
The tick size is very small (e.g. 1e-10)
Limit prices are very large (e.g. 1e10)
Prices are internally converted to “ticks” and maintained using a 64 bit integer. For the example just mentioned, it’s likely that the conversion will overflow.
Order books are now maintained such that overflow may be ignored. This in turn means that client logic can not rely on the accuracy of very high prices.
There are some alternatives which are not very attractive
Fail on overflow: This is only an option if the issues can be excluded, e.g. if only a few irrelevant symbols cause the issue. Otherwise it’s not an viable option.
Maintain prices using another storage class (than 64 bit integer): The system is designed for ultra low latency and anything else than integer operations will just be slow (e.g. something like a Decimal class). We favour speed and therefore reluctant to work with anything else than integers.
API, gateways and client samples can now be used with clang C++ on macOS (only X86_64 for now, M1 will likely be supported in the future).
This is still experimental and any bug reports will be greatly appreciated.
A number of utility functions, classes and templates have been promoted to the API. The intention is to make it easier to implement client logic.
A new example demonstrating how to manage the life-time of a secondary client thread responsible for passing
CustomMessageto the main dispatch loop.
The ClickHouse adapter has been upgraded to not use HTTP pipelining. The reason for previous instability turned out to be related to ClickHouse merging (and therefore discarding) updates thereby confusing the client.
The InfluxDB adapter is no longer maintained and will likely be discontinued. The reason is that the database simply isn’t a good fit. It lacks fundamental types (e.g. date and date-time) and doesn’t deal with NaN.