Support Board
Date/Time: Sat, 01 Mar 2025 08:11:45 +0000
[Programming Help] - New websocket
View Count: 2517
[2018-09-07 10:24:00] |
Rexz - Posts: 22 |
Hey SC team, Could you provide a little information on how to use the new websocket? Is there a way I can use API calls to return JSON data? Thanks |
[2018-09-08 20:52:08] |
|
We have added information about this here: Data and Trading Communications (DTC) Protocol Server: Server Usage Just follow through the step-by-step instructions. Although there really is not much additional added other than just simply a statement that a websocket connection can be used. 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: 2018-09-08 20:52:33
|
[2020-04-24 23:10:30] |
JasonS - Posts: 11 |
Hi, Are you able to please add some sample JSON request/responses in the documentation? Just so developers can have a basic understand of login procedure and retrieving account info, or something simple. Just having no example makes it difficult to understand what the correct format is. In regards to the LOGIN sequence, am I doing something wrong here? The client can conenct to the WSServer and send a message but the server does nothing. WSServer | DTC client #13. 192.168.1.4 (3) | Start Server | 2020-04-24 19:05:11.976 WSServer | DTC client #13. 192.168.1.4 (3) | Switch to HANDSHAKE | 2020-04-24 19:05:11.976 WSServer | DTC client #13. 192.168.1.4 (3) | Switch to READY_DATA | 2020-04-24 19:05:11.976 WSServer | DTC client #13. 192.168.1.4 (3) | Response HANDSHAKE with status code 101 | 2020-04-24 19:05:11.976 JSON data: { "ClientName": "python_ws_client", "HeartbeatIntervalInSeconds": 60, "Password": "xxxxx", "ProtocolVersion": 6, "TradeMode": 3, "Type": 1, "Username": "xxxxx" } | 2020-04-24 19:05:11.977 DTC client #13. 192.168.1.4 | No activity on network socket. Closing network socket. Bytes in receive buffer: 0 | 2020-04-24 19:05:32.009 DTC client #13. 192.168.1.4 (3) | CloseSocket call. | 2020-04-24 19:05:32.009 Deleting individual DTC server: DTC client #13. 192.168.1.4 | 2020-04-24 19:05:32.009 DTC client #13. 192.168.1.4 (3) | Shutdown started. Waiting for graceful close. | 2020-04-24 19:05:32.009 DTC client #13. 192.168.1.4 (3) | Socket gracefully closed by remote side. | 2020-04-24 19:05:32.010 DTC client #13. 192.168.1.4 (3) | Closed. | 2020-04-24 19:05:32.010 DTC server: DTC client #13. 192.168.1.4 successfully deleted. | 2020-04-24 19:05:32.010 Cheers Jason Date Time Of Last Edit: 2020-04-24 23:11:17
|
[2020-04-25 03:25:07] |
JasonS - Posts: 11 |
I realized I wasn't sending a null char on the end, so I added a null char, now I get a size error. Even when I send the correct size. Is this Size attribute needed for JSON? What's the error saying here? Received message with an invalid size (167)
DTC Protocol server | Incoming connection from 192.168.1.7. | 2020-04-24 23:22:07.937
DTC client #36. 192.168.1.7 (3) | Creating socket. | 2020-04-24 23:22:07.938 WSServer | DTC client #36. 192.168.1.7 (3) | Start Server | 2020-04-24 23:22:07.948 WSServer | DTC client #36. 192.168.1.7 (3) | Switch to HANDSHAKE | 2020-04-24 23:22:07.948 WSServer | DTC client #36. 192.168.1.7 (3) | Switch to READY_DATA | 2020-04-24 23:22:07.948 WSServer | DTC client #36. 192.168.1.7 (3) | Response HANDSHAKE with status code 101 | 2020-04-24 23:22:07.948 JSON data: {"ClientName": "DTC Client", "HeartbeatIntervalInSeconds": 120, "Password": "xxxxxx", "ProtocolVersion": 8, "Size": 167, "TradeMode": 3, "Username": "xxxxxx"} | 2020-04-24 23:22:07.959 DTC client #36. 192.168.1.7 | Received message with an invalid size (167). | 2020-04-24 23:22:07.959 * DTC client #36. 192.168.1.7 (3) | CloseSocket call. | 2020-04-24 23:22:07.959 Deleting individual DTC server: DTC client #36. 192.168.1.7 | 2020-04-24 23:22:07.959 DTC client #36. 192.168.1.7 (3) | Shutdown started. Waiting for graceful close. | 2020-04-24 23:22:07.959 DTC client #36. 192.168.1.7 (3) | Socket gracefully closed by remote side. | 2020-04-24 23:22:07.959 DTC client #36. 192.168.1.7 (3) | Closed. | 2020-04-24 23:22:07.959 DTC server: DTC client #36. 192.168.1.7 successfully deleted. | 2020-04-24 23:22:07.961 |
[2020-04-25 03:35:25] |
JasonS - Posts: 11 |
I figured it out. Yeh you don't need Size but you need Type of course. My code gen bugged out on Type, as soon as I put that back in it works!! DTC Protocol server | Incoming connection from 192.168.1.7. | 2020-04-24 23:30:36.399 DTC client #38. 192.168.1.7 (3) | Creating socket. | 2020-04-24 23:30:36.400 WSServer | DTC client #38. 192.168.1.7 (3) | Start Server | 2020-04-24 23:30:36.400 WSServer | DTC client #38. 192.168.1.7 (3) | Switch to HANDSHAKE | 2020-04-24 23:30:36.400 WSServer | DTC client #38. 192.168.1.7 (3) | Switch to READY_DATA | 2020-04-24 23:30:36.400 WSServer | DTC client #38. 192.168.1.7 (3) | Response HANDSHAKE with status code 101 | 2020-04-24 23:30:36.400 JSON data: {"ClientName": "DTC Client", "HeartbeatIntervalInSeconds": 120, "Password": "xxxxxx", "ProtocolVersion": 8, "TradeMode": 3, "Type": 1, "Username": "xxxxx"} | 2020-04-24 23:30:36.401 DTC client #38. 192.168.1.7 | Requested heartbeat interval: 40 | 2020-04-24 23:30:36.402 DTC client #38. DTC Client. 192.168.1.7 | Received logon request. | 2020-04-24 23:30:36.402 DTC client #38. 192.168.1.7 (3) | Send: {"Type":2,"ProtocolVersion":8,"Result":1,"Integer_1":0,"MarketDepthUpdatesBestBidAndAsk":0,"TradingIsSupported":0,"OCOOrdersSupported":0,"OrderCancelReplaceSupported":0,"SecurityDefinitionsSupported":1,"HistoricalPriceDataSupported":0, "ResubscribeWhenMarketDataFeedAvailable":0,"MarketDepthIsSupported":1,"OneHistoricalPriceDataRequestPerConnection":0,"BracketOrdersSupported":0,"UseIntegerPriceOrderMessages":0,"UsesMultiplePositionsPerSymbolAndTradeAccount":0, "MarketDataSupported":1,"ResultText":"Connected to SC DTC Protocol server. Service=sc_futures.dtc.trading|SymbolSettings=sc_futures.dtc.trading","ReconnectAddress":"","ServerName":"SC DTC Server","SymbolExchangeDelimiter":""} | 2020-04-24 23:30:36.402 DTC client #38. DTC Client. 192.168.1.7 | Sent successful Logon response message to client. Username: xxxxx. Result text: Connected to SC DTC Protocol server. Service=sc_futures.dtc.trading|SymbolSettings=sc_futures.dtc.trading | 2020-04-24 23:30:36.402 Date Time Of Last Edit: 2020-04-25 03:36:14
|
[2020-04-25 04:03:41] |
JasonS - Posts: 11 |
I've posted my sample code here: https://github.com/jseparovic/python-ws-dtc-client Just in case anyone is interested. I've generated the message type classes and the enums from the DTCProtocol.h file |
[2020-04-25 22:59:09] |
|
We will solve this: DTC client #36. 192.168.1.7 | Received message with an invalid size (167). | 2020-04-24 23:22:07.959 *
It is being displayed when there is no Type field at the beginning of the JSON message but the log message is not accurately indicating this.
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: 2020-04-25 22:59:21
|
[2020-04-26 23:59:48] |
JasonS - Posts: 11 |
I see incorrect field ordering in the following JSON compact encoding messages: MarketDataUpdateBidAskCompact: DTC client #91. 127.0.0.1 (1) | Send: {"Type":117,"F":[2114831995,282300,18,282350,19,1587943806]} | 2020-04-26 19:40:16.297 DTC client #91. 127.0.0.1 (1) | Send: {"Type":117,"F":[2114831995,282300,18,282350,9,1587943807]} | 2020-04-26 19:40:17.296 DTC client #91. 127.0.0.1 (1) | Send: {"Type":117,"F":[2114831995,282325,1,282350,9,1587943807]} | 2020-04-26 19:40:17.296 DTC client #91. 127.0.0.1 (1) | Send: {"Type":117,"F":[2114831995,282325,3,282350,9,1587943807]} | 2020-04-26 19:40:17.390 DTC client #91. 127.0.0.1 (1) | Send: {"Type":117,"F":[2114831995,282325,5,282350,9,1587943807]} | 2020-04-26 19:40:17.390 DTC client #91. 127.0.0.1 (1) | Send: {"Type":117,"F":[2114831995,282325,6,282350,9,1587943807]} | 2020-04-26 19:40:17.390 DTC client #91. 127.0.0.1 (1) | Send: {"Type":117,"F":[2114831995,282325,7,282350,9,1587943807]} | 2020-04-26 19:40:17.390 Order from DTCProtocol.h: float BidPrice; float BidQuantity; float AskPrice; float AskQuantity; t_DateTime4Byte DateTime; uint32_t SymbolID; Instead I'm seeing: uint32_t SymbolID; float BidPrice; float BidQuantity; float AskPrice; float AskQuantity; t_DateTime4Byte DateTime; MarketDataUpdateTradeCompact: DTC client #91. 127.0.0.1 (1) | Send: {"Type":112,"F":[2114831995,2,282350,4,1587943807]} | 2020-04-26 19:40:17.296 DTC client #91. 127.0.0.1 (1) | Send: {"Type":112,"F":[2114831995,2,282350,1,1587943807]} | 2020-04-26 19:40:17.296 DTC client #91. 127.0.0.1 (1) | Send: {"Type":112,"F":[2114831995,2,282350,1,1587943807]} | 2020-04-26 19:40:17.296 DTC client #91. 127.0.0.1 (1) | Send: {"Type":112,"F":[2114831995,2,282350,1,1587943807]} | 2020-04-26 19:40:17.296 DTC client #91. 127.0.0.1 (1) | Send: {"Type":112,"F":[2114831995,2,282350,1,1587943807]} | 2020-04-26 19:40:17.296 DTC client #91. 127.0.0.1 (1) | Send: {"Type":112,"F":[2114831995,2,282350,1,1587943807]} | 2020-04-26 19:40:17.296 DTC client #91. 127.0.0.1 (1) | Send: {"Type":112,"F":[2114831995,2,282350,1,1587943807]} | 2020-04-26 19:40:17.296 Order from DTCProtocol.h: float Price; float Volume; t_DateTime4Byte DateTime; uint32_t SymbolID; AtBidOrAskEnum AtBidOrAsk; Instead I'm seeing: uint32_t SymbolID; AtBidOrAskEnum AtBidOrAsk; float Price; float Volume; t_DateTime4Byte DateTime; |
[2020-04-27 03:59:30] |
JasonS - Posts: 11 |
I'm having another issue with DTC WS Connections, this time the problem is I'm not able to connect to the Historical Data Port. Connecting to the Listening Port works ok. (I'm using WebSocket Test Client Chrome Extension) DTC Protocol server | Incoming connection from 127.0.0.1. | 2020-04-26 23:50:08.617 DTC client #25. 127.0.0.1 (1) | Creating socket. | 2020-04-26 23:50:08.618 WSServer | DTC client #25. 127.0.0.1 (1) | Start Server | 2020-04-26 23:50:08.619 WSServer | DTC client #25. 127.0.0.1 (1) | Switch to HANDSHAKE | 2020-04-26 23:50:08.619 WSServer | DTC client #25. 127.0.0.1 (1) | Switch to READY_DATA | 2020-04-26 23:50:08.619 WSServer | DTC client #25. 127.0.0.1 (1) | Response HANDSHAKE with status code 101 | 2020-04-26 23:50:08.619 Connecting to the Historical Data Port does not complete the connection handshake and returns a connection error. HD Server Manager | Incoming connection from IP: 127.0.0.1 | 2020-04-26 23:52:25.790 HD Server Manager | Started new historical data server. Count=1 | 2020-04-26 23:52:25.790 Current thread priority: -1 | 2020-04-26 23:52:25.790 HD Server | Thread:7016 (1) | Creating socket. | 2020-04-26 23:52:25.795 HD Server | Timed out waiting for logon request. | Thread:7016 | 2020-04-26 23:52:36.850 HD Server | Thread:7016 (1) | CloseSocket call. | 2020-04-26 23:52:36.850 HD Server | Thread:7016 (1) | Shutdown started. Waiting for graceful close. | 2020-04-26 23:52:36.852 HD Server | Thread:7016 (0) | CloseSocket call. | 2020-04-26 23:52:36.852 HD Server | Thread:7016 (1) | Socket gracefully closed by remote side. | 2020-04-26 23:52:36.852 HD Server | Thread:7016 (1) | Closed. | 2020-04-26 23:52:36.852 HD Server | Server thread ending. Closing socket. | Thread:7016 | 2020-04-26 23:52:36.913 HD Server Manager | Current server count=0 | 2020-04-26 23:52:36.913 I've tried this in Python as well as the WebSocket Test Client and neither can connect to the Historical Data Port (both can connect to the Listening Port) |
[2020-04-28 00:50:47] |
|
That is true. The historical data port does not yet support the websocket protocol. We will look to see if this is easy to add support for. Regarding the field order mentioned in post #8, we are aware of that, but we cannot change it now without causing problem for existing programs that use the data. To avoid the use of compact messages and to use the more detailed trade message, specify the value of 12 in the Integer_1 Logon Request field. 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 |
[2020-04-28 00:55:03] |
JasonS - Posts: 11 |
Currently for the historical data port, do you support protobuf?
|
[2020-04-28 01:08:19] |
|
Yes protocol buffer encoding is supported with the historical data port. And we were successful with adding support for the websocket protocol. That will be out in the next release. 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 |
[2020-04-28 07:09:51] |
JasonS - Posts: 11 |
Just wondering about the compact JSON fields, do you have the field order changes documented? Would be good to update my codegen to set the correct order for all message types
|
[2020-12-25 03:23:53] |
RoadKill - Posts: 38 |
@JasonS I'm using WebSocket Test Client Chrome Extension
I'd like to use this to debug some python code. How do you format the Request massage in that browser plugin? ---------------------------------------------- EDIT I think I got it. I tested by sending this: \x0b\x00\x06\x00\x08\x08\x1a\x03DTC to: the intraday port on: 0.0.0.0:11099 ---------------------------------------------- EDIT No, that didn't work. It just show the same thing you sent. Date Time Of Last Edit: 2020-12-25 03:36:51
|
[2021-09-21 06:14:13] |
abuqutaita - Posts: 12 |
And we were successful with adding support for the websocket protocol. That will be out in the next release.
SC Team, Did this ever ship? I'm trying with SC version 2299 and I'm seeing the same results as previously posted: I can logon with the listening port but not complete the handshake with the historical data port. |
To post a message in this thread, you need to log in with your Sierra Chart account: