Support Board
Date/Time: Sat, 10 May 2025 08:34:06 +0000
DTC -> MarketDataRequest 92 bytes instead of 90 bytes
View Count: 1056
[2016-01-27 05:46:59] |
paska.houso - Posts: 7 |
Created a new thread to avoid polluting the DTC general thread. SierraChart is sending to my server, initial development and testing, a "MARKET_DATA_REQUEST" with "Size" set to 92 bytes. And the packet size is 92 bytes too. The header definition is: uint16_t Size; uint16_t Type; RequestActionEnum RequestAction; uint16_t SymbolID; char Symbol[SYMBOL_LENGTH]; char Exchange[EXCHANGE_LENGTH]; the constants: const int32_t SYMBOL_LENGTH = 64; const int32_t EXCHANGE_LENGTH= 16; the Enum: enum RequestActionEnum : int32_t My calculation gives: 2 + 2 + 4 + 2 + 64 + 16 = 90 Additionally: - This MARKET_DATA_REQUEST message is unsolicited, given that the LogonResponse of my server indicates that MARKET_DATA_REQUEST is not supported - RequestAction is set to 1 (SUBSCRIBE) in this message Date Time Of Last Edit: 2016-01-27 05:55:49
|
[2016-01-27 06:41:11] |
|
Refer to: https://en.wikipedia.org/wiki/Data_structure_alignment Sierra Chart does not currently pay attention to the MarketDataSupported field. But we can certainly add support for that. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
[2016-01-27 09:21:07] |
paska.houso - Posts: 7 |
Thank you for the answer. The MARKET_DATA_REQUEST message is not a real problem, just wanted to let you know. Data_structure_alignment at each side of the communication chain can happen. But sending data over the wire has to ensure that both ends agree on what's being sent. You may have chosen BINARY_ENCODING to be a 1:1 representation of what your compiler of choice happens to do with the structures ("pragma pack" is a Microsoft extension even if supported by other compilers like GCC), but this is not what the communication is supposed to deliver. This is not a complain or rant. I have no issue in adapting my code, but I guess sending the actual "packed/padded" C++ structure over the wire is not delivering (quoting from the docs) what's promised: "... in order to create reliable and plug-and-play interoperability ..." This link is the one where "Encodings" are defined: http://dtcprotocol.org/#MessageFormatEncoding For Binary Encoding the following applies: "... messages are encoded using fixed size binary data structures with embedded fixed length strings ...". Since the size relies on a C++ compiler feature, this break compatibility with other languages for which BINARY_ENCODING may be implemented. Rather than relying on the compiler to do the job, the structures should have "Reserved" fields which do the same job and ensure over the wire compatibility. And yes I know there is JSON_ENCODING and Google Protocol Buffers, but as it stands "BINARY_ENCODING" is not a protocol, but rather the transmission of a specific C++ compiler structure over the wire. |
[2016-01-27 09:39:20] |
|
In the next release of Sierra Chart, when you have set s_LogonResponse::MarketDataSupported to 0, then Sierra Chart will no longer send market data requests.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
To post a message in this thread, you need to log in with your Sierra Chart account: