The ACD allows us to define decoders in JSON configuration rather than C++.  Its primary purpose is to allow us to implement offset based decoders quickly. 

Once a protocol is implemented using this configuration, there is no release, retest and reinstall cycle for minor changes in the protocol’s specs.

Rather than needing development (sometimes by third-parties) against an SDK to respond to internal messaging changes, you can simply update the JSON configuration.

Here's an example configuration for decoding the header of the utp_line protocol, with placeholder message definitions.

{
"DecoderOptions" : {
"Name":"utp_line",
},
 
"TypeDefinitions": {
"UINT8": { "type": "uint", "size": 1},
"UINT64_BE": { "type": "uint", "size": 8, "endian": "big"},
"TIMESTAMP": { "type": "timestamp", "size": 8, "endian": "big"},
"ORIG": { "type":"string", "size": 2 }
"SYMBOL_STRING": { "type":"string", "size": 6 }
},
 
"MessageHeader" : {
"fields": [
{ "name": "Version", "type": "UINT8" },
{ "name": "Cat", "type": "UINT8" },
{ "name": "Type", "type": "UINT8", "flags":["msg_type"] },
{ "name": "Orig", "type": "ORIG" },
{ "name": "Timestamp", "type": "TIMESTAMP" },
{ "name": "Sequence", "type": "UINT64_BE", "flags":["seq_num"] },
{ "name": "Token", "type": "UINT64_BE" }
]
}
 
"Messages": {
"1": {
"name": "FirstMessageType",
"fields":[
{ "name":"Symbol", "type": "SYMBOL_STRING" }
]
},
"2": {
"name": "SecondMessageType",
"fields":[
{ "name":"OrderId", "type": "UINT64_BE"}
]
}
}
}


Limitations

ACD has a set of basic types which map onto VMX-Capture Datafield types (described in Type Definitions ).  Protocols always agree on basic integral computing units (e.g. byte, word, long), but there are data types which can't be supported in a generic way. 

Integer Price encodings can't currently be decoded to float datafields but can be decoded to integer datafields.

For example, a lot of Market Data protocols have a "Price" field which can be decoded as an integer but then this value has to be scaled by some protocol-specific scaling factor (e.g. 3 implied decimal places).  At the moment, ACD does not support a "Price" datatype, but can be added with an additional scaling factor to cater for most protocols.  This is not a guarantee of being able to support all variations of Price encodings.

ACD currently does not support the decoding of array types. 

For example, if a list of 16 bit instrument id's are encoded with a length (as is the case in the HKEX OMD protocol), these can't be decoded.  If you’d like us to add support for these type of naive array types, please speak to your Beeks Sales Representative or Client Contact.