Login Page - Create Account

DTC Protocol Discussion Forum


Date/Time: Fri, 29 Nov 2024 17:36:15 +0000



Open/Close for New Order Messages

View Count: 3228

[2015-09-09 22:57:56]
DTC Engineering - Posts: 320
The following field:
OpenCloseTradeEnum OpenOrClose;

Has been added to the following messages:
SUBMIT_NEW_SINGLE_ORDER
SUBMIT_NEW_SINGLE_ORDER_INT

SUBMIT_NEW_OCO_ORDER
SUBMIT_NEW_OCO_ORDER_INT


The header files have all been updated on this website and also the github repository will be updated during the hour.

The Sierra Chart test client does set this field in version 1294.
[2015-09-10 08:22:05]
vbmithr - Posts: 204
These messages needs a lot of padding, would be better to rearrange the fields differently.
[2015-09-11 23:06:08]
DTC Engineering - Posts: 320
Letting you know this is still contemplated. Changing this is not easy because the structures will not be back compatible.

We think it would be best if all of the enumerations are 8 or 16 bits instead of 32 bits.
[2015-09-11 23:57:06]
vbmithr - Posts: 204
Definitely yes! (The messages are shorter this way).

It is definitely not easy to modify things with a binary encoding where fields must have an order…
Since I'm actively developing, I don't care about backward compat.

Maybe, for protocol evolution, a binary protocol that enforce fields order/padding is just not feasible. The more you edit (and want to keep backward compat), the more the structures becomes big and not space optimized…

I'm really not so convinced about enforcing fields order since it is not convenient for gradual evolution.
[2015-09-12 00:28:23]
DTC Engineering - Posts: 320
If you want short messages though, you can use Binary Encoding with Variable Length Strings. That will give you the largest reduction in size.

For most of the messages there is not much to gain by changing some types from 32 bits to 8 or 16 bits and reordering them to minimize padding. The biggest reduction comes from shortening strings.

Have you calculated an example of how much a structure can be reduced by changing field ordering at reducing the enumeration size?
Date Time Of Last Edit: 2015-09-12 00:28:48
[2015-09-13 14:15:12]
vbmithr - Posts: 204
I think I'm gonna switch sooner or later to the protobuf encoding.

I can automatically generate printer/parser code for the protocol this way, which makes it really much convenient for me.
[2015-09-16 04:55:09]
DTC Engineering - Posts: 320
What we have thought of doing is for Binary Encoding with Variable Length Strings is we will redefine all of the enumerations to 8 bits.

So Binary VLS will be the most compact, flexible and efficient coding method. Even better than Google Protocol Buffers.

To post a message in this thread, you need to log in with your Sierra Chart account:

Login

Login Page - Create Account