Login Page - Create Account

Support Board


Date/Time: Mon, 23 Apr 2018 09:52:14 +0000



DTC Protocol

Support Request:
[2014-11-29 21:31:16]
Sierra Chart Engineering - Posts: 59332
Hello,

We have started initiative in this industry to establish a common communications protocol to connect Clients and Servers.

This is the official website:
Http://dtcprotocol.org

We are going to be putting a significant effort into this during the rest of the year. If you can keep your support questions to a minimum, that would be appreciated.

We are going to create two new encodings for the messages and fields.

This will be JSON and binary with variable length text strings.

We are going over all the messages and fields and improving the naming to make them as consistent, compact and logical as possible.

The trade order modify and cancel messages are being cleaned up a little by removing some unnecessary fields. We are also creating separate integer versions of order entry and modification functions.

We also have a proposal to Data and Trading services. We request that you contact us about adopting DTC and in return we are willing to offer Sierra Chart free to your customers for a period of one year if you adopt the DTC protocol in good faith, without the use of a bridge program, and you are a new service that Sierra Chart does not already support.

We also may offer discounts after the one year period.

This is not to be taken as an offer, but instead a request for negotiation. However, once we negotiate with the Data or Trading service successfully, we are willing to enter into a contract.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2014-12-06 03:08:03
[2014-12-04 20:52:06]
Sierra Chart Engineering - Posts: 59332
This may seem like a bold and unattainable initiative.

However, we hold the view that we will be very successful with this initiative.

And we are going to be a leader in transforming this industry to create plug-and-play interoperability between Clients and Servers exchanging financial market data, and trading commands and data.

We have no problem with being shunned, criticized or whatever with our initiative. In the end, people will see that this effort will succeed. We have no doubt about that. It may take years, but we will get there.

We are making very good progress at this time making all of the DTC message and field names, logical consistent and compact. Some of the naming, was based on the FIX protocol, but where something is not really logically or consistently named, we are changing it to what makes sense.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2014-12-04 20:55:55
[2014-12-18 07:49:13]
Sierra Chart Engineering - Posts: 59332
There are going to be a lot of enhancements to the DTC protocol in the next few months. There will be new encodings in addition to the current binary encoding with fixed length strings.

Sierra Chart also will support various connection configurations with the DTC Protocol. For example connecting separately for market data , historical price data, and trading each on a separate network connection.

We will also be developing our own trading simulation backend with OCO and bracket order support. The plan is this will be an open source project with open source code and using the DTC protocol.

Initially this will be supporting Forex data.

Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2014-12-18 07:50:02
[2014-12-20 01:12:51]
Sierra Chart Engineering - Posts: 59332
The DTC protocol has always supported multiple connections. For example, one for market data and another connection for trading.

With the support for different encodings like JSON, the market data connection can use the original binary encoding which is very efficient and the trading connection can use the JSON encoding, which is human readable and allows for the very easy insertion and removal of fields.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2014-12-23 21:34:25]
Sierra Chart Engineering - Posts: 59332
Another thought has come to mind in regards to the DTC protocol.

Sierra Chart currently offers now a relay server which has partial support for DTC:
http://www.sierrachart.com/index.php?page=doc/doc_RelayServer.php

This relay server only sends data and cannot respond to market data requests or historical price data requests.

We are going to make this into a full DTC server which exposes the full capabilities of DTC. It will support market data requests, historical price data requests, streaming real-time data, and order entry.


Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2014-12-24 02:25:17]
ejtrader - Posts: 533
SC Team - This is good news.

Looking forward to a basic test example to read the data using DTC server. Would be very beneficial.

Thanks
[2015-02-06 16:23:55]
User935308 - Posts: 2
Dear SC,

this is very good news.

Is the DTC Client implementation in SC somewhat mature?
I'm thinking about writing a DTC Server Bridge to my local broker and/or to push the broker to implement DTC Server natively.

So, please tell me if this project is mature enough to spend my relation capital with my broker.

PS: this broker has thousands of clients but an ugly platform, I think SC integration would boom.
[2015-02-06 17:27:39]
Sierra Chart Engineering - Posts: 59332
Is the DTC Client implementation in SC somewhat mature?
Yes it is because we are in the process of adding other encodings. We have already added support for binary message structures with variable length text strings and we are going to be working on JSON soon. We would not be working on other encodings if the DTC protocol messages and fields were not in a stable state.

You can find the documentation here:
http://dtcprotocol.org

What broker is this? We are planning to add support for IG Markets.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2015-02-10 07:45:42]
User935308 - Posts: 2
The broker is Directa, an italian broker.
It is one of the oldest in the world, offering online trading since 1996.

http://www.directa.it

I see that there is a C++ header file, with the data structures required to implement the DTC protocol.
Is DTC really a C++ only world, or it is really open to other languages?
I mean, I know it is a network protocol, and so it is possible to implement it in every language, but the binary encoding and the C++ header file makes me thinking about the convenience of implementing it in other languages (i'm thinking about java).
[2015-02-10 14:32:33]
ganz - Posts: 855
User935308

+1 for Java

and another one for a Python wrapper :)
[2015-02-10 16:13:03]
Sierra Chart Engineering - Posts: 59332
No. Definitely not. Any language can be used.

Is DTC really a C++ only world, or it is really open to other languages?

Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2015-03-08 19:45:27]
Jagui - Posts: 19
Hello,

I'm starting developing a DTC java bridge for my broker, and I would like to know if the work on JSON encoding is already started and when it will be available.

Thank you.
[2015-03-11 17:22:03]
Sierra Chart Engineering - Posts: 59332
We have not done the work on the JSON encoding, but we expect we will be starting on it this month and it should not take long.

So it is not far off from being complete.

Please check back in about two weeks.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2015-08-02 09:03:05]
Sierra Chart Engineering - Posts: 59332
Over the next couple months, we are going to begin development of the DTC Server in Sierra Chart.

We are going to be improving upon and completing some of the incomplete DTC documentation on the DTC protocol website.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2015-08-11 21:11:05]
Sierra Chart Engineering - Posts: 59332
The documentation for using Sierra Chart as a DTC Protocol Test Client has been completed and is here:
http://www.sierrachart.com/index.php?page=doc/doc_DTC_TestClient.php

In the next few days, Sierra Chart will support functioning as a test client using all 4 encoding methods:
http://www.sierrachart.com/index.php?page=doc/doc_DTCProtocol.php#MessageFormatEncoding
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2015-08-11 21:11:48
[2015-08-11 22:33:21]
Sierra Chart Engineering - Posts: 59332
Here is the DTC Protocol Discussion Forum:
http://dtcprotocol.org/SupportBoard.php?ForumID=50
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2015-08-12 02:27:37]
ejtrader - Posts: 533
it appears like this would require a new user registration to DTC website.

Is that intentional?

Thanks
[2015-08-12 06:53:57]
Sierra Chart Engineering - Posts: 59332
You can use your Sierra Chart Account Name and Password. We tested those and they work.

We also see we need to get a new security certificate for that site. That will be done tomorrow.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2015-08-12 06:59:10]
Sierra Chart Engineering - Posts: 59332
Another's feature that we are looking at which is likely to happen from this new DTC Protocol server will be a new feature where you can create a new instance of Sierra Chart directly from within Sierra Chart.

For example File >> New Instance.

This instance will access data from the original instance and then you can have multiple Chartbooks visible at the same time.

Basically this is supported now, but it will be much easier to use.

And you will be able to perform trading from these new instances using the single connection from the master/main instance.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2015-08-16 02:44:24
[2015-08-24 07:20:29]
Sierra Chart Engineering - Posts: 59332
By the end of August 2015 will be releasing support for Google Protocol Buffer encoding for the DTC Protocol. This brings the number of encodings to 5.

The supported encodings are documented here:
http://dtcprotocol.org/index.php?page=doc/doc_DTCProtocol.php#MessageFormatEncoding
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2015-08-24 16:39:56]
ejtrader - Posts: 533
SC Team - Would it be possible to provide any sample code for a DTC client to get the quote/level 2 data and if trading component is available - a sample of that would be helpful as well.

Thanks
[2015-08-24 18:50:32]
Sierra Chart Engineering - Posts: 59332
Yes. We are going to be creating a complete example program that demonstrates both the DTC client and server.

This will be a QT project. We hope this should be ready in about three weeks.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2015-08-26 07:37:20]
Dema - Posts: 19
This is excellent news. Please include samples for custom live market data feeds if possible!
[2015-08-26 07:47:13]
Sierra Chart Engineering - Posts: 59332
We do not know what is meant by "custom live market data feeds". In any case, it does not sound like something we would provide an example of.

In any case it should be obvious how to work with the protocol.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2015-08-26 08:24:14]
Dema - Posts: 19
Fair enough - if you're able to provide an example for market data as opposed to order data that would be sufficient.
[2015-10-10 04:02:29]
Sierra Chart Engineering - Posts: 59332
In this video, an AT&T representative back in 1985 talks about the benefits and coming changes from information technology and the information age:
https://www.youtube.com/watch?v=qWsC9KE-PHY

We believe this is kind of like the effort we are making now with the DTC Protocol. While it may take time to catch on, we have the future vision of something which is inevitable.

Update:

It was at roughly this point in the video:
https://youtu.be/qWsC9KE-PHY?t=909

Where the discussion reminded us of the DTC Protocol effort and how this can bring about great change and how it makes so much sense.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2015-10-10 05:16:46
[2015-10-10 04:38:33]
Sierra Chart Engineering - Posts: 59332
From this section here:
http://dtcprotocol.org/#WhyDTC

Here is a quotation:
DTC is completely neutral. What this means is that it does not favor the Client or the Server.

Think if a web browser had to be designed to work with a different protocol from every single website out there. Would that make sense? The obvious answer is that this does not make sense and this is why establishing a common open specification protocol is needed. The DTC protocol is the solution.

Standards are very common in electronic data communications and physical electronic networks. The Internet would not even be possible without standards. There is the TCP/IP standard. Hardware layers are highly standardized. There is a standard for Ethernet. There is no way that physical networks can interoperate without standardization.

Where would the Internet be without communication standards? The explosive growth seen on the Internet which began in the 1990s, throughout the first decade of the 21st century, and continues to this day, would not have taken place without standards.


Think about personal computers before USB? Think about all the trouble we had to get a piece of hardware hooked up to a computer before USB. In the old days, we had to deal with setting interrupt request numbers for a piece of hardware.

We hope people will begin to see the light here! We know many of our users do, but it is Trading services and Data services, which need to wake up and realize that eventually they are going to be isolated if they do not use standardized protocols.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2015-10-10 20:54:01
[2015-10-10 05:22:54]
Sierra Chart Engineering - Posts: 59332
Regarding this:


and another one for a Python wrapper :)

This is now supported with the DTC Protocol because the DTC Protocol now supports Google Protocol Buffering encoding which supports Python.

Have a look at:
https://developers.google.com/protocol-buffers/
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2015-10-12 01:38:53]
ejtrader - Posts: 533
SC Team - Did you had a chance to work on post #24 ( providing a working example ). Really looking forward to a working example on DTC client/server.

thanks
[2015-10-12 02:40:34]
Sierra Chart Engineering - Posts: 59332
Not yet. This is the next most significant item after the DTC Protocol Server is complete within Sierra Chart. That should be all done by the end of this week.

So probably next week we will start on the DTC client and server example code.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2015-10-14 17:50:00]
Guilherme - Posts: 62
Is there a FIX 4.X to and from DTC protocol bridge already available?
[2015-10-14 18:49:07]
Sierra Chart Engineering - Posts: 59332
No, this does not exist.

There is not a need for this because Sierra Chart already directly supports FIX.

Regarding Post #33, what is the purpose of using a FIX to DTC bridge?

Maybe we can help you if we have a better understanding of the need for it.

One difficulty though of bridging FIX to DTC is with order IDs. In FIX there are the following order IDs: OrderID , ClOrdID, OrigClOrdID. These are not directly mappable to DTC so there has to be some order ID management within the bridge program which does make it more complicated.

DTC just uses the ClientOrderID and ServerOrderID for simplicity. There really is not a need for more than this.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2015-10-15 00:52:33
[2015-10-15 00:52:46]
Sierra Chart Engineering - Posts: 59332
The prior post has been updated.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2015-11-20 18:38:22]
ejtrader - Posts: 533
Not yet. This is the next most significant item after the DTC Protocol Server is complete within Sierra Chart. That should be all done by the end of this week.

So probably next week we will start on the DTC client and server example code.

SC Team - post #31 - Still very much looking forward to these examples - even if they are in "raw" form :) Hopefully would have a chance to explore these during the holiday season.

thanks
Date Time Of Last Edit: 2015-11-20 18:39:27
[2015-11-21 02:02:53]
Sierra Chart Engineering - Posts: 59332
We are behind on this, and it seems unlikely we will have this done before the end of the year. But we would not think it would be longer than the end of January.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2016-01-19 11:12:18]
paska.houso - Posts: 7
Dear SierraChart Team, I had a look at your application and had a project in my backlog to implement a DTC Server in Python.

With the advent of 2016 I have started that and rather than hand-coding everything and risking falling behind potential changes, I have written a small C++ Header Parser (specifically suited for the DTCProtocol.h). The syntax allows that and with an "almost" automatic translation to Python.

I have only come to 3 corner cases, 2 of which you may possibly and easily iron out. Here my feedback (C++ Fixed Length Strings)

1. Some of the "structs" define a "Clear" method which is invoked from the constructor. This should either be the standard for ALL structs or not be present in anyone. Consistency is key. The "Clear" method does not only clear standard "operating" values of the "struct" but also things like the "Size" and "Type" fields, which can be seen as an integral part of each instance.

I would personally opt for having a Clear Method for each and every struct.

2. Two of the structs feature a "SetToUnsetValues" method which is doing more or less (it doesn't touch Size/Type) than Clear. The most annoying thing about this method is that unlike "Clear" ... it is not defined in the header file but rather in the "cpp" part. If "Clear" breaks consistency, this "SetToUnsetValues" goes a step beyond.

In this case you could put the functionality of "SetToUnsetValues" into a "Clear" method in the header and then have the "SetToUnsetValues" call "Clear" (for backwards compatibility)

Structs with this method: s_MarketDataSnapshot (call to it missing in the constructor) and s_MarketDataSnapshot_Int

3. Nested "struct" by having 2 arrays of s_DepthEntry structs as members of s_MarketDepthFullUpdate20 and s_MarketDepthFullUpdate10. Although for a regular API this is no issue, for an over-the-wire transmission it is not. It is not because these two do not resist the comparison with all other structs which are made up of simple types. Encoding/Decoding over-the-wire packets may be as simple as doing a "memcpy" in C/C++, but this adds an unneeded burden on Dynamic Languages in which the exact representation of double and floats (for example Python) is not simply a set of bytes, but rather and object.

Of course it can be overcome and given these 2 structs are already well defined, there is no easy way out. But let me suggest that future structures should avoid declaring composite types.

In any case and as soon as I am reasonable satisfied with my development, it will be available on GitHub.

Best regards

P.S.
Having your files and documents on GitHub would also be a good idea to allow people to propose changes/corrections/improvements via Pull Requests (GitHub is just a suggestion, many other sites fare also as good)
[2016-01-19 12:37:33]
Guilherme - Posts: 62
Have you considered using Protocol Buffer encoding? I'm using it in my Java/Scala implementation for DTC Protocol. It really made my life a lot easier.
[2016-01-19 13:25:19]
paska.houso - Posts: 7
It is my aim to implement all the Encodings if possible (under Python JSON Encoding would be the most obvious choice) but wanted to start with the lowest common denominator which should be Binary.

In any case my points 1 and 2 are Encoding-Independent.
[2016-01-20 08:11:08]
Sierra Chart Engineering - Posts: 59332
1. We are working on implementing the Clear function for all message structures in the header file.

2. We will replace the SetToUnsetValues functions with a Clear function in the header file.

3. Noted but the structures cannot be changed at this time. However, it really is recommended that you use: s_MarketDepthSnapshotLevel instead

The 10 and 20 levels market depth structures are not really meant to be part of the official protocol. They are there for ease-of-use.


4. Here is the public repository:
https://github.com/DTC-protocol
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2016-01-20 09:26:26]
paska.houso - Posts: 7
1. Thanks (I already tweaked my rudimentary parser to implement the Clear method even if missing in the sources)

2. Thanks too (I also tweaked my parser to 1st read the c++ implementation and scan any SetToUnsetValues and make a "Clear" out of it)

3. Thanks for the tip. I will stick to it.

4. Thanks again. Somehow and even after searching in the docs for it I was unable to find a link

Best regards
[2016-02-28 00:25:04]
ejtrader - Posts: 533
SC Team - Wondering if you would have a chance to work on the example code you have referred to in Post #31 and #36.

Thanks

Not yet. This is the next most significant item after the DTC Protocol Server is complete within Sierra Chart. That should be all done by the end of this week.

So probably next week we will start on the DTC client and server example code.

We are behind on this, and it seems unlikely we will have this done before the end of the year. But we would not think it would be longer than the end of January.

[2016-02-28 22:09:29]
Sierra Chart Engineering - Posts: 59332
Not yet. We are working hard over the next three months to catch up on overdue tasks.

But we are not sure when we can get to this. We should have a better idea in about a month.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2016-02-28 22:09:40
[2016-03-08 00:30:18]
User716386 - Posts: 4
Hi,

Unfortunately, As I understand DTC/FIX bridge example not in Your priority list.

Please let me know how I can connect new FIX based brokers to Sierra.

I would like connect accounts from:
- PrimeXM FIX;
- CFH Clearing API v 2.5 (FIX 4.4 based)

I already use them from my own strategies, but I'll be happy integrate it to Sierra.

Best Regards
[2016-03-08 04:04:40]
Sierra Chart Engineering - Posts: 59332
We do not ever remember saying that we would provide an example of a DTC to FIX bridge. We only said that an example of the DTC client and server would be provided, but that would only be helpful for those who have little programming experience/knowledge.

There is no reason if you know what you are doing that you should need these examples. You should be completely fine without them especially if you have experience with FIX and network connections.


Please let me know how I can connect new FIX based brokers to Sierra.

Want kind of answer are you looking for? This is far too involved for us to answer.

You have to write a DTC server and use the DTC client in Sierra Chart:
http://www.sierrachart.com/index.php?page=doc/doc_DTC_TestClient.php
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2016-03-08 04:05:12
[2016-03-23 21:41:03]
User783015 - Posts: 7
I am trying to write a DTC client Python class which my trading software will use to connect to Sierra Chart DTC server. I'd like to use the JSON encoding for obvious reasons. However the EncodingRequest message must be sent in a binary format and that's quite a problem. I got a crazy idea to write a small C++ application which would construct this message and store it to a file. This would allow me to take that string, hardcode it to my Python script and send it over the socket to force the server to JSON encoding. But there must be an easier way to do this, right?

Looking into it a bit more, the s_EncodingRequest structure is much more complex than I originally thought. I now see all the methods it is implementing and I assume that when you serialize the structure to send it over the wire, you're including also all the method code in the binary message. I was thinking about using the protocol buffers but there's the same problem again - first you need to send the EncodingRequest message in the binary format to request the encoding change. The whole point of using JSON or protocol buffers is to enable interoperability with languages which may use different binary representation of data than C++ and converting the data to this binary format may be tedious, right? Forcing the application to send the EncodingRequest message in the binary format imho defeats that point. If I'm writing a DTC client which may connect to different unknown DTC servers, I'm pretty much forced to write the client in C++.

Or am I missing anything?
Date Time Of Last Edit: 2016-03-23 22:32:50
[2016-03-24 00:23:04]
vbmithr - Posts: 204
I got a crazy idea to write a small C++ application which would construct this message and store it to a file.

You don't have to do this. Indeed you need to support the handshake procedure using the binary encoding but anything you can do in C++ you can do it in Python too.

you're including also all the method code in the binary message.

Yes you are missing the point that the binary encoding is just a serialization format for sending a message over the wire. The fact that they provide a C++ header file is irrelevant, I coded www.bitsouk.com in OCaml, never needed a line of C++.

The header file (DTCProtocol.h) defines C++ structures. You need to understand how those datastructures are represented in memory and send a message of this exact same format. The representation in memory is simple (fields are just added in order), but sometimes the compiler do padding.

I recommand using protocol buffers because you benefit from the provided protocol description and don't have to follow protocol upgrades. You just have to handle logon request and encoding request/response from the binary protocol (I think).
[2016-03-24 01:11:25]
Sierra Chart Engineering - Posts: 59332
The Encoding Request is a very simple data structure consisting of 16 bytes.

How numbers and text are encoded is standardized. The only variation is some hardware platforms use what is called big endian byte ordering instead little endian. But the overwhelming amount of systems out there use little endian. This only applies to integer and floating-point numbers.

Anyway what we will do in the DTC Server in Sierra Chart is we will add an option to force a particular encoding so you do not have to bother with the encoding request and response.

We will have this out next week.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2016-03-24 01:24:03
[2016-03-24 19:59:39]
User783015 - Posts: 7
Thanks a lot for your replies!

I understand that the binary encoding is just a serialization format for sending the message over the wire. The challenge is how do I create a data structure in Python which will result in a binary data stream identical to the one produced by the C++ structure defined in the DTC protocol - in other words the binary data stream which the DTC server is expecting.

Python is a dynamically typed scripting language - you do not define a data type when you declare/define a variable. Consider the following python code:

import sys
var = 5
print( sys.getsizeof( var ) )

The output I get is "24" (on a 64-bit Win7 machine). So my tiny integer number is stored in a 24 byte big int memory space.

My point is that every language may use totally different binary encoding of its data and high level scripting languages like Perl or Python handle this in the background and don't even "bother" the user with these internals. Trying to make two different languages talk to each other in a binary format may be problematic. After some googling around I found https://docs.python.org/3.0/library/struct.html which should probably do what I'm looking for. But the question is how many other languages have something like that.

I would suggest to reconsider using the binary format as the default encoding for DTC. While you can construct a JSON file using any language you want - even as primitive as a batch file - constructing a binary message may be significantly more difficult. I guess that's also why the RESTful APIs became so popular - they allow very simple and limitless interoperability between different languages and even platforms. Using such a platform independent (yet less efficient, I agree) encoding by default, you may significantly increase the chances of wider adoption of the DTC protocol.


And thanks, SC Support, for the offer to add the encoding selection to the Sierra Chart DTC Server! I'll play with the Python struct module above but I will gladly use that new feature.

Happy Easter!
Petr
[2016-03-24 20:15:26]
Sierra Chart Engineering - Posts: 59332
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2016-03-24 21:42:24
[2016-03-24 20:46:31]
Guilherme - Posts: 62
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]
Sierra Chart Engineering - Posts: 59332
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2016-03-24 21:56:44]
ejtrader - Posts: 533
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]
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]
Guilherme - Posts: 62
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]
Sierra Chart Engineering - Posts: 59332
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2016-03-30 00:01:17]
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]
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]
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]
Sierra Chart Engineering - Posts: 59332
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2016-03-30 01:13:35
[2016-03-30 01:22:58]
Sierra Chart Engineering - Posts: 59332
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2016-03-30 02:07:01]
Sierra Chart Engineering - Posts: 59332
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2016-03-30 02:11:18
[2016-03-31 21:32:01]
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]
Sierra Chart Engineering - Posts: 59332
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2016-04-01 00:00:20]
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]
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]
Sierra Chart Engineering - Posts: 59332
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2016-04-25 10:58:16]
Guilherme - Posts: 62
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]
Sierra Chart Engineering - Posts: 59332
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2016-04-25 16:53:44
[2016-06-07 07:33:03]
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]
Sierra Chart Engineering - Posts: 59332
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2016-06-16 07:52:41]
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]
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]
Sierra Chart Engineering - Posts: 59332
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2016-06-16 08:34:04
[2016-06-16 08:37:19]
Sierra Chart Engineering - Posts: 59332
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. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2016-08-10 00:47:14]
ejtrader - Posts: 533
Still looking for any example code to be populated at this link. It's been really a very LONG wait on this..

Looking for a DTC server example code..


http://www.dtcprotocol.org/#DTCProjects
[2016-08-12 04:53:40]
Sierra Chart Engineering - Posts: 59332
Due to our development schedule, there is no way we can possibly get this done at this time. Therefore, do not expect it will be done. You will be waiting at least another year or more.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2016-08-22 08:00:53
[2016-08-22 08:00:18]
Sierra Chart Engineering - Posts: 59332
Post 77 has been revised.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2017-01-09 16:00:16]
User69508 - Posts: 2
Dear Sierra,

I want to develop a trade copier/account manager software for Sierra, main feautre is to trade the master platform and send the orders to the clients. Read all what found about this, still have basic questions. First want to understand how the orders routed and sent to the broker. Got an C++ expert programmer, he can make it Im sure. Read the protocol manual but please clarify first is my thinking good or you can give better solution:

1. I still dont understand the connections, the clients must connect to their broker - if I set the connection to DTC server, how can the client trade its account?

2. Simplest solution looks to catch the orders from Sierra on the master account, make a server which send the data to the clients. Where can I get the trade window data?

3. Is the DTC capable for this purpose (control an instance for trading)?

thanks, Peter
[2017-01-22 20:30:10]
Sierra Chart Engineering - Posts: 59332
We apologize for overlooking this posting (#79).

You had posted into a very long discussion thread which is a sticky at the top of this board and sometimes postings under these conditions will get overlooked.

You really should have started a new Support Request. This way the questions will not be missed.

We need to understand what you are asking about better.

What do you mean by "master platform"? And what do you mean by this:
"send the orders to the clients"?

Specifically what is the client?

1. What do you mean by:
- if I set the connection to DTC server,

This is inconsistent with the Sierra Chart functionality. We need precise information to understand what you mean.

2. We are not understanding any of this. You need to be very clear about specifically how you are using Sierra Chart by specifying specific actions and settings.

In regards to Trade Window data, specifically what data are you referring to?

3.

Is the DTC capable for this purpose (control an instance for trading)?

It is possible to use Sierra Chart as a DTC server and for other Sierra Chart clients to connect to it to access the trading service which is used by Sierra Chart acting as a server.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2017-01-22 20:31:26
[2017-05-03 04:30:53]
User280048 - Posts: 1
Good news! Looking forward to a basic test example to read the data using DTC server!
Date Time Of Last Edit: 2017-05-15 14:47:11
[2017-05-18 02:16:58]
Sierra Chart Engineering - Posts: 59332
For the DTC Protocol Historical Data Server in Sierra_Chart, all encoding types are now supported including JSON and Google Protocol Buffers.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2017-07-12 10:06:50]
Mack - Posts: 30
I'm interested in using Python to execute trades and retrieve data from SC. I'm just reading up on the DTC protocol and wonder if anyone has managed to use Python to connect to SC successfully. Would be very glad to get some pointers where to start.
[2017-07-12 16:19:40]
Sierra Chart Engineering - Posts: 59332
If you want to use Python, we recommend using Google Protocol Buffer encoding. Google Protocol Buffers do support Python.

We would not expect any difficulty.

References:
https://developers.google.com/protocol-buffers/
http://dtcprotocol.org/
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2017-07-12 16:20:34
[2017-07-14 18:05:58]
rhovega - Posts: 266
Is there a DTC server working code example coming soon? Its been two years. Be great to know if to wait for it or to look into alternatives. Thanks.
[2017-07-20 07:48:12]
Sierra Chart Engineering - Posts: 59332
No it would not come soon. This task has been put on hold indefinitely.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2017-08-09 06:10:14]
User563013 - Posts: 10
Can I use DTC to pull indicator data from a chart? Or more specifically chart study data?
Date Time Of Last Edit: 2017-08-09 06:18:17
[2017-08-09 16:47:38]
Sierra Chart Engineering - Posts: 59332
No, for this you will need to use ACSIL:
https://www.sierrachart.com/index.php?page=doc/AdvancedCustomStudyInterfaceAndLanguage.php
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2017-10-25 16:57:57]
AndrewAMD1 - Posts: 23
I have a technical question, as I am writing a DTC client for Sierra Chart.

Suppose I have a position of negative five lots, and I want to reverse it to positive five lots.

I see these enumerations:
TRADE_UNSET = 0
TRADE_OPEN = 1
TRADE_CLOSE = 2

Do I have to:
* Place two buy order of 5 lots each, one to close and one to buy?
* Place one order of 10 lots, unset? open? close?
Date Time Of Last Edit: 2017-10-25 16:59:06
[2017-10-25 18:06:40]
Sierra Chart Engineering - Posts: 59332
This depends upon the particular Trading service that the order is being submitted to.

Which one is that?

We would recommend using TRADE_UNSET and just one order.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2017-10-25 18:39:26]
AndrewAMD1 - Posts: 23
I was hoping to write this client in a universal manner so that others can use it too with any broker/trading service. (If you must know, I'm doing a demo of CQC via Amp, and I'll probably buy into it at the beginning of next month.)

So is this a trial-and-error thing, then?
[2017-10-25 19:03:57]
Sierra Chart Engineering - Posts: 59332
Would be best therefore to use two separate orders in this case.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2017-10-26 07:47:23]
Anne Gladbo - Posts: 9
Is there anyone out there who has succeded getting the data into Python using the DTC protocol? If so, would you be kind enough to put an example in Github (or similair) and post a link here - or post an example here.
It would be greatly appriciated! I have no experience whatsoever with protocol buffer or basically any of the other options mentioned in this thread.
Thanks!
[2017-10-27 11:27:13]
User754985 - Posts: 94
Would be best therefore to use two separate orders in this case.

This would be inefficient commissions- and slippage-wise.
Which Trading services supported by SC would really require 2 orders?
[2017-10-27 17:23:09]
Sierra Chart Engineering - Posts: 59332
In response to post #93, you could use JSON encoding to make it easier:
https://www.sierrachart.com/index.php?page=doc/DTCProtocol.php#JSONEncoding

2 orders would be required for BitMEX and TD Ameritrade.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2017-10-30 19:39:51]
AndrewAMD1 - Posts: 23
I'm writing code in C++, and the variable binary encoding is a little tricky to implement compared to fixed-struct binary. I'm wondering if it's worth my time to implement my trading client in variable.

Are there any rule-of-thumb performance metrics? Obviously, size will vary, but how much can I expect bandwidth to shrink using variable? That is, what percentage of fixed message size is a typical variable size?
[2017-10-31 01:05:56]
Sierra Chart Engineering - Posts: 59332
but how much can I expect bandwidth to shrink using variable?
Not by much because most messages are market data messages and do not use any strings to begin with.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2017-10-31 01:06:08
[2017-11-30 17:17:59]
AndrewAMD1 - Posts: 23
Regarding specifically Sierra Chart's platform DTC servers:

How can my client perform sanity checks that the charting platform is indeed in TradeMode = LIVE, DEMO, or SIMULATED?

I tried sending a logon request with the TradeMode field set, and apparently my Sierra Chart ignored the (optional) field.
[2017-11-30 19:35:11]
Sierra Chart Engineering - Posts: 59332
There really is no way to know this from the DTC client. Trade Simulation Mode within Sierra Chart can be enabled and disabled at any time by the user.

The client is not notified of these changes and there is no message indicating the change of that state.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2017-11-30 19:35:43
[2017-11-30 19:39:57]
Sierra Chart Engineering - Posts: 59332
Really, it is the TradeAccount field with orders, which controls whether the order is intended to be simulated or not. Here is more information about that:
https://www.sierrachart.com/index.php?page=doc/NewInstance.php#UsingCorrectTradeAccount
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2017-11-30 20:35:20]
AndrewAMD1 - Posts: 23
So just to confirm, the only way to know for sure is to submit orders?

Below are nine scenarios. I expect six of the scenarios to result in rejected orders. Is my understanding correct?

Client sends SIMULATED order:
1a) SC: SIM enabled (expect: accept)
1b) SC: SIM disabled, logged into DEMO account (expect: reject)
1c) SC: SIM disabled, logged into LIVE account (expect: reject)

Client sends DEMO order:
2a) SC: SIM enabled (expect: reject)
2b) SC: SIM disabled, logged into DEMO account (expect: accept)
2c) SC: SIM disabled, logged into LIVE account (expect: reject)

Client sends LIVE order:
3a) SC: SIM enabled (expect: reject)
3b) SC: SIM disabled, logged into DEMO account (expect: reject)
3c) SC: SIM disabled, logged into LIVE account (expect: accept)
[2017-11-30 22:01:44]
Sierra Chart Engineering - Posts: 59332
Start a new Support Request for this.

This thread is already very long. This is getting into a very specific detailed question.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2017-12-22 10:53:12]
User14532 - Posts: 6
Hello
I am downloading data from sierraChart for my adudoco.com/keystrategy . I am loading .scid files from disk or importing through the DTC protocol. I want to implement the (.dly) daily format support. Loading data from disk files is not a problem. But I do not know what DTC datarequest needs to be sent to sierraChart for the (.dly) text format.
Is it even possible or is there any HTTP GET request for this case?
Thanks for help
[2017-12-23 05:23:20]
Sierra Chart Engineering - Posts: 59332
There is no HTTP protocol for historical daily data in Sierra Chart.

You need to use the DTC Protocol:
https://www.sierrachart.com/index.php?page=doc/DTCServer.php#HistoricalPriceDataServer


In the historical price data request:

https://www.sierrachart.com/index.php?page=doc/DTCMessages_HistoricalPriceDataMessages.php#Messages-HISTORICAL_PRICE_DATA_REQUEST


For this parameter:
https://www.sierrachart.com/index.php?page=doc/DTCMessageDocumentation.php#HistoricalDataIntervalEnum


Use:
INTERVAL_1_DAY
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2017-12-26 02:07:57]
EricH - Posts: 17
My current system is 100% matlab with Interactive broker API for data and trade.
I am exploring the possibility to migrate the broker interface part to DTC and use SC as the data/trade backend.
One thing I found that's unique in IB is it has a 5-sec 'real-time bar'.
https://interactivebrokers.github.io/tws-api/realtime_bars.html#gsc.tab=0

Looking thru the DTC protocol spec, what's the best way to 'emulate' this 5-sec bar?

Obviously the two options are 1)subscribe to realtime data and build the 5 sec bar myself, but I really don't want all those extra messages of MARKET_DATA_UPDATE_* except TRADE, I don't even want the SNAPSHOT. However in the request enum, there's no "UPDATE_TRADE" only option...

option 2) is to actively pull historical every 5 sec, with the interval set to be 5sec, and set the request begin_time so that only one (or two most) records are sent to me.

Please advise if there're other options, and if there'll be some performance hit for option 2) if many symbols quotes are involved, and all requests are triggered at the 5-sec 'edges'.
[2017-12-26 03:41:08]
Sierra Chart Engineering - Posts: 59332
1. This is the best and most proper way.

2. This will be fine, but you have to reduce the Intraday file flush time so no data is lost:
https://www.sierrachart.com/index.php?page=doc/DataSourceSettings.php#IntradayFileFlushTimeInMilliseconds
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2017-12-29 00:17:10]
EricH - Posts: 17
continue on DTC historical data access, the 'StartDateTime' of the return record(non tick, say 1-min bar requested), is it the first trade timestamp within the minute, or you actually return the minute-bar boundary?

From my limited experiment now, it seems it's the timestamp of the first trade within the minute bar, correct?
[2017-12-29 06:04:09]
Sierra Chart Engineering - Posts: 59332
it seems it's the timestamp of the first trade within the minute bar, correct?
Yes.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2018-04-22 18:29:34]
User942837 - Posts: 55
Hi,

1) the HistoricalDataIntervalEnum seems that it does not cater for any minute data > 1M because it skips directly to 1D after 1Min. Do you have any plans say to implement any other time interval? Because if I want data for example for 60M intervals, I would have to download data for Interval1Minute which is pointless. I know this could be reconstructed but makes it much easier to request the timeframe requested. Am I missing something? Also if I want to get OHLC for RTH session session, I do not see a way to restrict start and end time like you would in Chart Settings. Any plans to implement this?

2) Are there any plans for DTC to process Time Related interval messages. E.g. If I want to get OHLC data at the close of the last bar, do I have to figure out the OHLC myself from message MARKET_DATA_UPDATE_TRADE_COMPACT 112 or is there a better way to do this? Would really make things better if a client can receive a notification message at the last bar closed on any requested timeframe.

Thank you

To post a message in this thread, you need to login with your Sierra Chart account:

Login


Login Page - Create Account