Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Mon, 06 May 2024 08:51:34 +0000
Post From: I'm considering switching to your data from DTN iqfeed ...
| [2020-12-08 17:26:19] |
| Agent Orange - Posts: 36 |
|
Thanks for pointing me in the right direction. Not only did it save me a lot of time, it looks like I should be able to make the switch from DTN iqfeed to your stock and market stats feed very soon since your protocol is so straightforward. I did, however, in writing my initial test case, run into a time consuming issue which I think could be avoided by a small change in the DTC protocol documentation (or perhaps in the SC DTC server implementation): I am, at the moment, using exclusively JSON, so I set the DTC server accordingly. When I first sent my LOGON message to the DTC server, I saw in the SC message log that it had received my request, but I got nothing back until the server complained about not seeing a HEARTBEAT message within 20 seconds. I spent an embarrassingly long time trying to figure out why I was seeing no response, but thinking it might be a programming language incompatibility between C/C++ and Java, I eventually stumbled on an old but relevant support board post (Trying to run JAVA demo program | Post: 129218): ====================================== Sierra Chart Engineering [Direct Messages] - Posts: 91899 | Ending Date: 2021-04-05 Make sure you send a null terminator byte after that JSON message. Otherwise, Sierra Chart is not going to process the received message and this is what we believe the problem is due to. ====================================== And, of course, once I sent that null terminator, I was back in business. It then also became clear that the SC DTC server sends a null terminator after each JSON message it sends. It was trivial to append a null terminator to my messages and discard them from the sever messages once I knew about this requirement, but it seems to me it's a deviation from the DTC protocol as documented. I figured this whole thing might be related to zero terminated strings in C and C++, and I might have thought of that sooner except for the fact that my LOGON message was showing up in the SC log (meaning SC knew it had received a well formatted JSON string ending with a } but still wasn't responding). So unless I missed something in the documentation (forgive me, if so), either the documentation should be changed to specify these null terminators as being required or the built in SC DTC server shouldn't look for them or send them out, and hopefully this will save others some time and make your excellent protocol even easier to use. Thanks ... |