Home >> Support Board

Support Board

Date/Time: Fri, 29 Nov 2024 18:30:24 +0000

How to Post a Message for Support

[Locked] - DTC Protocol

View Count: 85232

[2016-03-24 20:15:26] #50 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
The DTC protocol does not have a default encoding. The binary encoding was the first encoding but it should not be considered the default. However, the encoding request is a binary data structure. It is part of the protocol that both the Client and Server can agree upon a particular encoding to use and completely bypass the encoding request and response. We have already added the option to specify the default encoding in the DTC Server in Sierra Chart and it will be out later today. 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 Date Time Of Last Edit: 2016-03-24 21:42:24

[2016-03-24 20:46:31] #51 [Go To First Post]
Guilherme - Posts: 66
Hi, Petr. DTC binary encoding has nothing to do with the language and types you use. You can implement in in any language. By the way, I'm using Scala for both Server and Client. Here is some code for you to get some idea: // Encoding request is: 16 0 6 0 7 0 0 0 4 0 0 0 68 84 67 0 // 16 bytes, mensagem tipo 6, DTC version 7, encoding type 4, "DTC/0" // Encoding response is: 16 0 7 0 7 0 0 0 4 0 0 0 68 84 67 0 def createBinaryEncodingRequest(): ByteString = { // Hardcoded encoding response expected by SierraChart. val output = ByteBuffer.allocate(16).order(ByteOrder.LITTLE_ENDIAN) output.putShort(16) // message size output.putShort(DTC_PB.DTCMessageType.ENCODING_REQUEST_VALUE.toShort) //message type: encoding request(equals 6) output.putInt(protocolVersion) output.putInt(4) // encoding type 4: requesting Protocol buffer format output.put('D'.toByte) output.put('T'.toByte) output.put('C'.toByte) output.put(0.toByte) val o = output.array() ByteString(o) } def createBinaryEncodingResponse(): ByteString = { // Hardcoded encoding response expected by SierraChart. val output = ByteBuffer.allocate(16).order(ByteOrder.LITTLE_ENDIAN) output.putShort(16) // message size output.putShort(DTC_PB.DTCMessageType.ENCODING_RESPONSE_VALUE.toShort) //message type: encoding response(equals 7) output.putInt(protocolVersion) output.putInt(4) // encoding type 4: tell the client that the server will use Protocol buffer output.put('D'.toByte) output.put('T'.toByte) output.put('C'.toByte) output.put(0.toByte) val o = output.array() ByteString(o) } []s Guilherme Date Time Of Last Edit: 2016-03-24 20:49:40

[2016-03-24 21:45:56] #52 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
Anyone who is doing development with the DTC Protocol for something that will be made available to other users, we will provide Sierra Chart usage time at no cost. 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-03-24 21:56:44] #53 [Go To First Post]
ejtrader - Posts: 688
Would really appreciate if someone can publish a sample working code for both DTC Client & Server. Have been waiting for a sample working code for a long time now. Thanks

[2016-03-27 17:35:37] #54 [Go To First Post]
User783015 - Posts: 7
Thanks Guilherme! This is exactly what I was looking for (the binary representation of the encoding request message): // Encoding request is: 16 0 6 0 7 0 0 0 4 0 0 0 68 84 67 0 This is the method I'm using in my Python client to send the encoding request to Sierra Chart: import struct ... # Send encoding request to the server def encoding_request( self ): if self.dtc_socket_connected: # The encoding request must be sent in a binary format message = struct.pack( "<2H2i4c" , 16 , ENCODING_REQUEST , DTC_PROTOCOL_VERSION , JSON_ENCODING , 'D' , 'T' , 'C' , chr( 0 ) ) print( "Sending encoding request message" ) self.dtc_socket.sendall( message ) return 1 else: return 0 I was expecting to get a response in the binary format as well, instead of that I got a JSON response already: $ ./DTCCliPy.py Sending encoding request message Server encoding response: {Type:7,ProtocolVersion:7,Encoding:2,ProtocolType:"DTC"} Is this expected? The DTC protocol documentation website (http://dtcprotocol.org/index.php?page=doc/doc_DTCMessageDocumentation.php#EncodingRequest) states: In either case, the ENCODING_RESPONSE is sent using the encoding the ENCODING_REQUEST was sent using, which must be Binary Encoding if it is the first message at the beginning of the network connection. All subsequent messages are sent using the new encoding if it was accepted by the Server. I'm more than happy parsing the JSON response rather than the binary message. On the other hand there seems to be an inconsistency between Sierra Chart DTC server behavior and the DTC protocol specification ;) Thanks, Petr UPDATE: I spent significantly more time on this today and my code is shaping up pretty well. I have one additional question though: Sierra Chart exposes two DTC servers - one for historical data on port 11098 and one for real-time data on port 11099. These two DTC servers behave differently in regard to the ENCODING_RESPONSE message which I mentioned above. HD server responds to my initial JSON encoding request in binary encoding (expected according to DTC protocol definition), the second on 11099 responds to my initial JSON encoding request in JSON encoding (the inconsistency I reported above). I have updated my client side code to detect the encoding of the ENCODING_RESPONSE message and process it accordingly. The HD server is giving me a logon error "Username not specified" which I'll read about a bit more - I guess the historical data DTC server requirements are different than for the real-time data service (which returns logon success even if I don't specify any credentials). Date Time Of Last Edit: 2016-03-27 21:29:14

[2016-03-27 21:21:37] #55 [Go To First Post]
Guilherme - Posts: 66
I've passed through all these questions you have now. But my main development is a DTC server, using Sierra as the client. My understanding is that since the request was in binary encoding format, the response should be in that format too. And after this, all messages should be using json (in you case). When implementing a server and connecting to it with Sierra, I was receiving a binary encoding request and sending back a protocol buffer message, but Sierra could not understand it yet. I had to answer with a binary encoding response and after that I could use protocol buffer normally.

[2016-03-27 22:02:18] #56 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
On the other hand there seems to be an inconsistency between Sierra Chart DTC server behavior and the DTC protocol specification ;) Yes you are right there is an inconsistency and this is an error. We have now fixed this and we will have a new release out before morning. Furthermore in the latest prerelease we have already added the capability to set the encoding for the DTC Server in Sierra Chart. Update following the instructions here: https://www.sierrachart.com/index.php?page=doc/download.php#FastUpdate You should not have any concern updating to the prerelease. It is stable. As a matter fact you must update because there has been a significant stability problem with the DTC historical data server which has been fixed. 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-03-30 00:01:17] #57 [Go To First Post]
User783015 - Posts: 7
Thanks, I have updated to the pre-release and I'm running Sierra Chart 1389 now. I am playing with the Sierra Chart historical data service but I'm having some problems receiving the historical data. I'm using JSON encoding. I send the HISTORICAL_PRICE_DATA_REQUEST message to SC, receive the HISTORICAL_PRICE_DATA_RESPONSE_HEADER as expected but at that point when I should start receiving HISTORICAL_PRICE_DATA_RECORD_RESPONSE messages, Sierra starts throwing some binary data at me which I don't understand. Here's the output from my script: $ python -u DTCCliPy.py DBG: DTCCliPy: Connected to localhost:11098 DBG: DTCCliPy: Sending encoding request (requested encoding: JSON) DBG: DTCCliPy: RCV: 10 00 07 00 07 00 00 00 02 00 00 00 44 54 43 00 DBG: DTCCliPy: Binary encoding response received: '(16, 7, 7, 2, 'D', 'T', 'C', '\x00')' DBG: DTCCliPy: Sending logon request: '{Type:1,ProtocolVersion:7,HeartbeatIntervalInSeconds:60,ClientName:"TestClient",Username:"user"}' DBG: DTCCliPy: Logon response received: '{Type:2,ProtocolVersion:7,Result:1,Integer_1:0,MarketDepthUpdatesBestBidAndAsk:0,TradingIsSupported:0,OCOOrdersSupported:0,OrderCancelReplaceSupported:1, SecurityDefinitionsSupported:0,HistoricalPriceDataSupported:1,ResubscribeWhenMarketDataFeedAvailable:0,MarketDepthIsSupported:1,OneHistoricalPriceDataRequestPerConnection:1, BracketOrdersSupported:0,UseIntegerPriceOrderMessages:0,UsesMultiplePositionsPerSymbolAndTradeAccount:0,MarketDataSupported:0,ResultText:"Logon successful.", ReconnectAddress:"",ServerName:"SC HistoricalDataServer",SymbolExchangeDelimiter:""}' DBG: DTCCliPy: SC HistoricalDataServer: Logon successful. DBG: DTCCliPy: Sending historical data request: '{Type:800,RequestID:1,Symbol:"ADSK",RecordInterval:86400,StartDateTime:1458430359,UseZLibCompression:0}' DBG: DTCCliPy: Historical data response received: '{Type:701,MessageText:"Data is being downloaded from a remote source. Download will start when this is done."}' DBG: DTCCliPy: Ignoring response type 701 DBG: DTCCliPy: Historical data response received: '{Type:801,RequestID:1,RecordInterval:86400,UseZLibCompression:0,NoRecordsToReturn:0,IntToFloatPriceDivisor:0}' DBG: DTCCliPy: RCV: 58 00 23 03 01 00 00 00 80 39 ef 56 00 00 00 00 00 00 00 e0 51 d8 4c 40 00 00 00 00 29 1c 4d 40 00 00 00 c0 f5 88 4c 40 00 00 00 80 c2 15 4d 40 00 00 00 00 fc 20 35 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Traceback (most recent call last): File "DTCCliPy.py", line 357, in <module> dtc_client.historical_data_response( ) File "DTCCliPy.py", line 332, in historical_data_response response = struct.unpack( "<2Hiq5dI2dB" , message ) struct.error: unpack requires a string argument of length 77 First I tried to parse the binary data I'm receiving 58 00 23 03 01 00 00 00 80 39 ... as a binary HISTORICAL_PRICE_DATA_RECORD_RESPONSE message. But the binary data don't match that message - I'm expecting 77 bytes message but the first 2 bytes suggest the size of 88, the second 2 bytes suggest a message type 8963 which is invalid.. So I have two questions: - why am I receiving binary stream instead of JSON data? - what does the binary stream mean? Am I by any chance receiving ZLib compressed data even though I didn't ask for them? Any help appreciated, this doesn't look like something I will be able to figure out on my own. This is what I see in the SC log: HD Server \| New server thread for client has been created for incoming connection. \| 2016-03-30 01:32:39 HD Server \| Received login. Requesting authorization. \| Username: user. \| 2016-03-30 01:32:39 HD Server \| Login has been authorized. \| Username: user. \| 2016-03-30 01:32:39 HD Server \| HD Request \| Symbol: ADSK \| ServiceCode: \| RecordInterval: 86400 \| MaximumDaysRequested: 0 \| Start Date-Time: 2016-03-19 23:32:39 \| ClientRequestID: 1 \| Username: user. \| 2016-03-30 01:32:39 HD Request # 17 \| Downloading Historical Daily chart data for ADSK. Starting date: 2016-03-28. Service: equities.us \| 2016-03-30 01:32:39 HD Request # 17 \| Using user Barchart Historical data account. \| 2016-03-30 01:32:39 HD Request # 17 \| Requesting historical Daily data for ADSK starting at 2016-03-27 \| 2016-03-30 01:32:39 HTTP connection to ds01.ddfplus.com:80 (0) \| Resolved address ds01.ddfplus.com to IP 8.18.161.123. \| 2016-03-30 01:32:39 HTTP connection to ds01.ddfplus.com:80 (127) \| Connected. \| 2016-03-30 01:32:40 HD Request # 17 \| Receiving historical Daily data for ADSK starting at 2016-03-28 \| 2016-03-30 01:32:40 HD Request # 17 \| Writing historical Daily data to the file ADSK.dly \| 2016-03-30 01:32:40 HD Request # 17 \| Received 2 records from 2016-03-28 00:00:00 to 2016-03-29 00:00:00 (2.0 days) and wrote 2 records for ADSK \| 2016-03-30 01:32:40 HD Request # 17 \| Daily download COMPLETE for ADSK. Completion time: 0s. Unique request ID: 16 \| 2016-03-30 01:32:40 Removed historical data download ID 16 \| 2016-03-30 01:32:40 HD Server \| HD Request # 1 \| Symbol: ADSK \| ServiceCode: \| RecordInterval: 86400 \| Records Served: 6 \| ClientRequestID: 1 \| Username: user. \| 2016-03-30 01:32:40 Socket (0) \| Closed. Windows error code 10053: An established connection was aborted by the software in your host machine. \| 2016-03-30 01:32:40 Socket (0) \| Shutdown and closed. \| 2016-03-30 01:32:40 Btw. it seems to be using barchart. Is this expected? I thought that SC provides its own historical data service. The whole point of my exercise is to overcome the limitation IB have on their historical data (60 requests per 10 minutes). I need to download latest data snapshot for 500+ stock tickers before the end of regular trading hours which my system uses to make trading decisions. Is this something I can achieve with SC? Thanks! Petr Date Time Of Last Edit: 2016-03-30 00:02:56

[2016-03-30 00:28:49] #58 [Go To First Post]
vbmithr - Posts: 204
Hi Petr, I advise you to use the protobuf encoding for SC. I did implement the fixed-length binary protocol entirely for a project, but if it was to be redone I would use protobuf, because with this you will always be automatically up to date with DTC no matter how it evolves (whereas with other encoding you have to follow changes). For your question, 0x0323 = 803, you're receving an historical price data record response. I bet SC sends you the data in the the binary protocol.

[2016-03-30 00:49:46] #59 [Go To First Post]
User783015 - Posts: 7
Ah, you're right. The byte order is reversed.. I will look at the protocol buffers at some point too I think. I'm just experimenting with it now to understand how it behaves, what data I get etc. The JSON format is pretty readable so it's good for these experiments. Still, the JSONs returned from Sierra Chart are not completely valid since the parameter names are not quoted so the Python json library will not parse them. I had to create a simple parser on my own.

[2016-03-30 01:13:18] #60 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
Still, the JSONs returned from Sierra Chart are not completely valid since the parameter names are not quoted so the Python json library will not parse them. Yes you are correct: https://en.wikipedia.org/wiki/JSON#Data_types.2C_syntax_and_example Not sure why we did it this way but we will correct this. We should have a release out tomorrow with this corrected. 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 Date Time Of Last Edit: 2016-03-30 01:13:35

[2016-03-30 01:22:58] #61 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
The DTC Historical Data Server in Sierra Chart is designed to only use DTC::BINARY_ENCODING. This is documented here: https://www.sierrachart.com/index.php?page=doc/doc_DTCServer.php#HistoricalPriceDataServer It should not have accepted the request for the JSON encoding and we have corrected that. However, if that is what you want to use, we should be able to make that work but just give us about a week. You will be able to accomplish what you want as there are no restrictions like you have with Interactive Brokers TWS. 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-03-30 02:07:01] #62 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
We just remembered why the historical data server does not use JSON encoding or Google protocol buffers. It is designed to be very fast and efficient. We are not going to be able to support JSON with it at this time. Or at least we are not likely to get to this for a couple of months. 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 Date Time Of Last Edit: 2016-03-30 02:11:18

[2016-03-31 21:32:01] #63 [Go To First Post]
User783015 - Posts: 7
Ok, I understand. I would be very grateful if you could implement the JSON support sometime in the future though. Working with the binary format in a language like Python is incredibly frustrating. It takes long time to construct the necessary struct format strings and I still seem to get different results than expected. Now I'm struggling with the logon response message from the SC historical data service. The structure definition looks like this (I put the particular field sizes on the left): struct s_LogonResponse { 2 uint16_t Size; 2 uint16_t Type; 4 int32_t ProtocolVersion; 4 LogonStatusEnum Result; 96 char ResultText[TEXT_DESCRIPTION_LENGTH]; 64 char ReconnectAddress[64]; 4 int32_t Integer_1; 60 char ServerName[60]; 1 uint8_t MarketDepthUpdatesBestBidAndAsk; 1 uint8_t TradingIsSupported; 1 uint8_t OCOOrdersSupported; 1 uint8_t OrderCancelReplaceSupported; 4 char SymbolExchangeDelimiter[SYMBOL_EXCHANGE_DELIMITER_LENGTH]; 1 uint8_t SecurityDefinitionsSupported; 1 uint8_t HistoricalPriceDataSupported; 1 uint8_t ResubscribeWhenMarketDataFeedAvailable; 1 uint8_t MarketDepthIsSupported; 1 uint8_t OneHistoricalPriceDataRequestPerConnection; 1 uint8_t BracketOrdersSupported; 1 uint8_t UseIntegerPriceOrderMessages; 1 uint8_t UsesMultiplePositionsPerSymbolAndTradeAccount; 1 uint8_t MarketDataSupported; When I add all the sizes together, I get a message size of 253. But SC HD service is sending me a message with the size of 256 so when I try to parse it response = struct.unpack( "<2H2i96s64si60s4B4s9B" , message ) it fails because the message doesn't have the expected size. $ python -u DTCCliPy.py DBG: DTCCliPy: Connected to localhost:11098 DBG: DTCCliPy: Sending encoding request (requested encoding: Binary) 10 00 07 00 07 00 00 00 00 00 00 00 44 54 43 00 DBG: DTCCliPy: Binary encoding response received: '(16, 7, 7, 0, 'D', 'T', 'C', '\x00')' DBG: DTCCliPy: Sending binary logon request 00 01 02 00 07 00 00 00 01 00 00 00 4c 6f 67 6f 6e 20 73 75 63 63 65 73 73 66 75 6c 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 53 43 20 48 69 73 74 6f 72 69 63 61 6c 44 61 74 61 53 65 72 76 65 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 01 00 01 01 00 00 00 00 00 00 00 Traceback (most recent call last): File "DTCCliPy.py", line 392, in <module> if not dtc_client.connect( ): File "DTCCliPy.py", line 153, in connect if self.logon_request( ) and self.logon_response( ): File "DTCCliPy.py", line 293, in logon_response response = struct.unpack( "<2H2i96s64si60s4B4s9B" , message ) struct.error: unpack requires a string argument of length 253 What are those 3 extra bytes I'm getting? I feel like I'm getting crazy from this. Haven't done so many dec <-> hex conversions since my fun time with assembler :) Of course I can just parse those extra 3 bytes and ignore them. But I would like to understand why my expectations don't match with what I'm getting. The help page http://dtcprotocol.org/index.php?page=doc/doc_DTCMessages_AuthenticationConnectionMonitoringMessages.php#Messages-LOGON_RESPONSE lists the parameters in a different order than the s_LogonResponse structure definition in the DTC header file. I'm using the structure definition since that one seems to match (except for those 3 bytes) the data I'm getting. Btw. please let me know if this is not the right place to put all these questions. I will surely have more during my DTC client development project and I don't want to spam this thread if you planned to use it for a different purpose. If there's another place I should be posting these questions, let me know. Thanks, Petr Date Time Of Last Edit: 2016-03-31 22:48:14

[2016-03-31 23:31:05] #64 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
Repost this here: http://dtcprotocol.org/SupportBoard.php The extra bytes are going to be from structure padding. 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-04-01 00:00:20] #65 [Go To First Post]
vbmithr - Posts: 204
See my code here: https://github.com/vbmithr/ocaml-dtc/blob/master/lib/cstructs.ml This is OCaml (well an OCaml extension to parse C structures), and you can see where fields are padded when I add a field like named like _padding (sometimes there are multiple padding fields). The rules are that types (short, int, long, …) are aligned by a multiple of their size, i.e. for example a short cannot start on byte 5, a long (64 bits) cannot start on byte 6, and so on…, so that if you, say, have a structure like struct MyStruct { char a; uint64 b; } the size will not be 9, but 16, and equivalent to struct MyStruct { char a[8]; uint64 b; } That's why I advise you to use the protobuf encoding (and you advised yourself to use JSON). It is tedious to deal with those padding oneself. Date Time Of Last Edit: 2016-04-01 00:01:23

[2016-04-01 01:39:47] #66 [Go To First Post]
User783015 - Posts: 7
Thanks a lot for the info! This explains the "anomalies" I'm seeing. Unfortunately - as SC Engineering mentioned above - the Sierra Chart historical data DTC server doesn't support any other encoding than binary at the moment. So I will need to deal with this. Should be much easier now that you explained how this works though. Much appreciated!

[2016-04-01 06:09:16] #67 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
Not sure how significant this is on newer CPUs but the reason that padding exists is so that the data is properly aligned in order to improve the speed of transfer of data to and from the CPU. 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-04-25 10:58:16] #68 [Go To First Post]
Guilherme - Posts: 66
How do I appply for Sierra Chart usage time at no cost? I'm implementing a DTC server in Scala/Java, and using Sierra only for testing my own server, not connecting to any other market data provider. []s

[2016-04-25 16:51:48] #69 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
Make this request here: https://www.sierrachart.com/usercp.php?page=SupportTickets 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 Date Time Of Last Edit: 2016-04-25 16:53:44

[2016-06-07 07:33:03] #70 [Go To First Post]
romulko - Posts: 2
Hello there. I try to connect java through DTC Protocol > Google Buffer > compile into java source > connect to the SC. When I send pure bytes (Encoding request is: 16 0 6 0 7 0 0 0 4 0 0 0 68 84 67 0) that Guilhermer mentioned above - the SC sucsessfuly returned result. But when I try to encode Java class DTCProtocol.EncodingRequest into byte code - there a bit different byte code in the result: DTCProtocol.EncodingRequest encodingRequest = DTCProtocol.EncodingRequest.newBuilder() .setEncoding(DTCProtocol.EncodingEnum.PROTOCOL_BUFFERS) .setProtocolVersion(DTCProtocol.DTCVersion.CURRENT_VERSION.getNumber()) .setProtocolType("DTC") .build(); bytes = encodingRequest.toByteArray(); bytes = [8, 7, 16, 4, 26, 3, 68, 84, 67]; Am I do something wrong? Thanks.

[2016-06-07 08:00:46] #71 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
Here is the binary encoding data structure for an encoding request: struct s_EncodingRequest { uint16_t Size; uint16_t Type; int32_t ProtocolVersion; EncodingEnum Encoding; char ProtocolType[4]; } Make sure the byte ordering is little endian. 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-06-16 07:52:41] #72 [Go To First Post]
romulko - Posts: 2
Unfortunately, I have no knowledge in c++ and that's why I have no idea how to serialize this structure and take a look at its encoded bytes to compare it to my output of the encoded java EncodingRequest class. So the first thing that I'm asking you to do, to help not c++ developers, is to give us bytes of this structure s_EncodingRequest that you expect on SierraChart side. Thank you. Looking forward for your answer. Date Time Of Last Edit: 2016-06-16 07:54:42

[2016-06-16 07:59:22] #73 [Go To First Post]
vbmithr - Posts: 204
The fields are packed in order, 8 bytes aligned. That is, supposing the address of the first field is zero, the fields of size n can only start at an entire multiple of n. And the byte order is little endian. Padding is added in the serialization in order to ensure that all fields start at an address that is a multiple of their size. See https://github.com/vbmithr/ocaml-dtc/blob/master/lib/cstructs.ml in order to see where to add padding. Hope this helps.

[2016-06-16 08:33:51] #74 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
In response to post 72, are you writing a DTC Client or Server? In response to post 73, DTC::s_EncodingRequest contains no padding. 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 Date Time Of Last Edit: 2016-06-16 08:34:04

[2016-06-16 08:37:19] #75 [Go To First Post]
Sierra Chart Engineering - Posts: 104368
If you are writing a DTC Client for Sierra Chart you just need to set Global Settings >>Data/Trade Service Settings >> SC Server Settings >> Encoding to the encoding you want to use and you do not need to send the encoding request at all. 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: