DTC Protocol Discussion Forum
- DTC Protocol Discussion Forum |
- Search Board |
- Control Panel |
- View My Posts / Threads |
- Direct Messages
Date/Time: Fri, 29 Nov 2024 10:26:59 +0000
Please update DTC protocol documentation and header files
View Count: 5682
| [2022-03-25 12:36:10] |
| User406106 - Posts: 6 |
|
It seems that the documentation has not been updated recently. There are multiple messages that contain much more fields than it is documented. Even the HEARTBEAT message, which supposed to be 16 bytes as per the docs and the C++ header file at https://dtcprotocol.org/DTC_Files/DTCProtocol.h is much, much longer now as the server sends me 62 byte heartbeats. Judged by the incoming messages when I switch to JSON protocol I can see that there are at least 10 undocumented fields in the messages. Besides, the currently available DTCProtocol.h seems to be not just incomplete but also incorrect here and there. For example: // From DTCProtocol.h lines 3101..3104 (struct s_OrderUpdate): char PreviousClientOrderID[ORDER_ID_LENGTH]; char FreeFormText[ORDER_FREE_FORM_TEXT_LENGTH]; t_DateTimeWithMillisecondsInt OrderReceivedDateTime; // this gives me invalid dates, but works with t_DateTime t_DateTimeWithMilliseconds LatestTransactionDateTime; And again, based on the JSON messages at least one Username field is undocumented. Could you please make an up-to-date DTCProtocol.h available containing the latest message definitions? I understand that updating the docs may take a longer time but the updated header would also be a great help for now. |
| [2022-03-31 15:45:40] |
| |
|
These will not be documented because they are Sierra Chart specific and internally used: Even the HEARTBEAT message, which supposed to be 16 bytes as per the docs and the C++ header file at https://dtcprotocol.org/DTC_Files/DTCProtocol.h is much, much longer now as the server sends me 62 byte heartbeats.
The latest header files have now been released on the DTCProtocol.org website. t_DateTimeWithMillisecondsInt OrderReceivedDateTime; // this gives me invalid dates, but works with t_DateTime This is a UNIX time value in milliseconds as an integer. Sierra Chart could be sending this though in microseconds.Where: And again, based on the JSON messages at least one Username field is undocumented.
If there is any missing documentation other than what you have specifically mentioned let us know. |
| [2022-04-01 14:08:47] |
| User406106 - Posts: 6 |
|
Thank you for updating the header file, it is much appreciated. These will not be documented because they are Sierra Chart specific and internally used
If so, would it be possible not to send the internal-only optional fields via the DTC protocol? Our platform has a high severity alert if a DTC message contains unprocessed or wrongly parsed fields. Please omit the message parts that we must ignore anyway. This is a UNIX time value in milliseconds as an integer. Sierra Chart could be sending this though in microseconds.
But it isn't, that's what I try to highlight. I'm aware of the differences of Sierra's date-time formats, that's why I could fix the issue. The header file is incorrect (the new one, too), because this field should have t_DateTime type, not t_DateTimeWithMillisecondsInt. Interestingly enough, it is incorrect only in the header file, whereas the .cpp contains the correct type: t_DateTime s_OrderUpdate::GetOrderReceivedDateTime() Example (let's use JSON encoding for better readibility): {[...]"OrderReceivedDateTime":1648819962,"LatestTransactionDateTime":1648819964.947[...]}
If I parse 1648819962 as t_DateTimeWithMillisecondsInt I get 1970-01-20 2:00 But if I parse it as t_DateTime I get the correct 2022-04-01 13:32 As for context (see also the attached screenshot): We use the C++ sources only as reference. Our platform has a meta description for all message types we need to use so it can (de)serialize the messages using any encoding (binary/var length binary/JSON/Compact JSON/protobuf). |
 2022-04-01_160129.png / V - Attached On 2022-04-01 14:02:35 UTC - Size: 42.71 KB - 550 views |
| [2022-05-04 13:44:39] |
| |
|
This will be corrected in the next release: The header file is incorrect (the new one, too), because this field should have t_DateTime type, not t_DateTimeWithMillisecondsInt. Interestingly enough, it is incorrect only in the header file, whereas the .cpp contains the correct type: t_DateTime s_OrderUpdate::GetOrderReceivedDateTime()
We see why there was this inconsistency. Although Sierra Chart does use this particular 64-bit Date-Time integer, to hold a millisecond timestamp. So it is a thousand times higher when Sierra Chart is using these messages. Although you would not have these millisecond timestamps, when using the DTC Server but it is possible to signal Sierra Chart to do that. Date Time Of Last Edit: 2022-05-04 13:45:17
|
To post a message in this thread, you need to log in with your Sierra Chart account: