The Data and Trading Communications Protocol is an unlicensed public-domain protocol, as developed and published by the engineers at Sierra Chart. Using this protocol, a client and a server would exchange financial messages, such as:
- Logon, authorization, heartbeats, and logoff
- Market data, including market depth
- Order placements, modifications, and cancellations, including OCO orders
- Order tracking, including open orders and historical orders
- Market position tracking
- Account balance tracking
- Symbol definitions and discovery
- Historical financial data
In addition, any server has the option of supporting custom messages for any purpose.
A DTC server can pick and choose which encodings it will support. There are five encodings to choose from:
- Binary Encoding
- Messages consist of fixed-size structs. This is quite easy to implement in C/C++, and very low bandwidth.
- Binary w/ Variable Length Strings Encoding
- Similar to the standard binary encoding, but the strings can have variable length. This has the advantage of minimum bandwidth, and the disadvantage that it is a little complicated to implement. Also, the bandwidth reduction will only affect strings, so this reduction will have zero effect on numerical data such as market data or historical data. This could be implemented in C/C++.
- JSON Encoding
- Every message is a JSON object. This is the option with maximum bandwidth, since all messages are in plain text. I cannot recommend this encoding at all, since a more compact version exists.
- Compact JSON Encoding
- Google Protocol Buffers
- A proto2 file and a proto3 file are available to generate message classes in C++, C#, Java, Dart, Go, and Python, and that’s just the officially supported languages. These classes can be used to serialize and deserialize data to and from a binary socket stream. I suspect that this method is fairly efficient with bandwidth but adds some processing overhead. This can be a good choice if backwards compatibility, minimal code maintenance, maximum language compatibility, and low bandwidth are all high priorities.
DTC officially supports connectivity via:
- TCP Socket
- Web Socket
These sockets can be encrypted or unencrypted, as the server sees fit. The general recommendation is to use TLS 1.2 encryption, as of this writing.
My Experiences with the DTC Protocol
I wrote a DTC client in C++. It was a DLL broker plugin for the Zorro Trading Automaton. Other than some challenges related to running background threads from a DLL (which I will not discuss here), the protocol has been fairly easy to work with.
I was slightly disappointed to learn that Sierra Chart’s DTC server does not support the full spectrum of message types. For example, the Symbols for Underlying Request is not supported, so I cannot list out all available symbols for a given option or future.
How to Rapid-Prototype a DTC Client or DTC Server
If you want to try out the DTC protocol today, I have good news for you: You can prototype your DTC clients and DTC servers by testing it out with a copy of Sierra Chart.
I did mention that DTC has an integrated server, but you can also use it as a DTC Test Client.
In conclusion, you can make a prototype DTC client by connecting it to Sierra Chart, and a prototype server by serving Sierra Chart. After this, you should feel free to re-use the client or server in any application you see fit.