Login Page - Create Account

Support Board


Date/Time: Thu, 23 May 2019 22:09:34 +0000



Post From: True Data India Data Feed: Public Offer (Currently Withdrawn)

[2016-02-29 03:33:05]
Sierra Chart Engineering - Posts: 72106
There has been interest in Sierra Chart supporting the data feed from True Data in India:
https://www.truedata.in/

Sierra Chart currently does support Global Data Feeds using a FIX connection but they have had problems with their FIX data feed and are no longer offering it because of problem reports. So effectively it is not available.

This particular issue is a Global Data Feeds issue and not with Sierra Chart.

Getting back to True Data, we contacted True Data back in 2015 and found out that kind of interface to their service that they use is an E-Signal compatible interface which uses an in process API or something like that.

This is not acceptable to us as we do not support those components. Our position on this is here:
Http://www.sierrachart.com/index.php?page=doc/helpdetails76.html

We asked them to support the DTC Protocol and gave them a financial incentive to do so and they said they were planning to do that. The offer was not accepted in a reasonable amount of time and as the end of 2015 came the offer was withdrawn because it was a very valuable offer far in excess of the cost of their development and we questioned whether they would be putting together a good quality server.

They also told us they are developing some kind of HTTP type of interface to their data feed. So we thought it would be best for us to program to their HTTP to interface instead.

We inquired about the status of the availability of their HTTP interface about the middle of February. We thought this was some kind of web-based HTTP type of interface. They came back to us with an undocumented interface which requires that we create a DLL which interfaces into a client-side executable and then we then bridge Sierra Chart to the DLL by using an interprocess communication method.

This is a highly unusual interface that we have never seen before and effectively it is an in process API type of component because we would have to write code which interfaces into the address space of the proprietary executable program. These types of components are not supported and this is explained here:
http://www.sierrachart.com/index.php?page=doc/helpdetails76.html

They are utilizing a local client-side server to serve multiple charting and trading applications. This type of design is acceptable and we can work with it so long as it provides interface through a local TCP/IP network socket connection. This is not what it provides.

Interactive Brokers and DTN IQ Feed also provide a local client-side server program to serve multiple charting and trading applications. Each of those provides an interface through a local TCP/IP network socket connection. The specific communication over the connection is proprietary but the general method in which they work is that they accept request messages and send back response messages and streaming data. All of this is just based on common sense.

So we do not understand the basis of the True Data interface . Certainly we were never consulted and this is inconsistent with norms in this industry. So all of this is rather puzzling to us.

The interface approach the True Data has taken really surprises us, because it we have seen a move away from these proprietary executable based methods of integration. Virtually no one out there is doing anything like this these days because they all realize it is complicated, OS and compiler specific, proprietary and has various issues and limitations.

Therefore, we have no intention of programming to this Windows/Microsoft/True Data proprietary DLL interface because it is against our policy and will be the source of problems and difficulties for us and for users. Our policies are based upon a huge amount of experience and common sense.

We are once again, interested in having True Data adopt the DTC Protocol:
HTTP://DTCProtocol.org

Basically we will make Sierra Chart available for use with the True Data feed at reduced prices up to a certain amount of sales to give them them a financial incentive to adopt the DTC Protocol. The exact pricing we will privately communicated to True Data.


This is an offer for a unilateral contract which can be accepted on the part of True Data by them initiating the development of a DTC compatible Server. We will provide the technical help they need and we will expect that this is done to a high-quality and proper standard.

As soon as True Data begins the development on this effort, the offer cannot be withdrawn by us under the common law of contracts.

However, if True Data still has an HTTP interface coming, we are interested in that and perhaps that is what we will use rather than them developing a DTC compatible server. However, the streaming portion of their HTTP service, could use a web socket and DTC compatible messages. So before they do any development on this, they need to consider this and consult with us. Once again they do not have to write any documentation because the DTC documentation already exists.


Below is the most recent message from True Data:

Our model has been worked out in a manner to enable a client to connect multiple TA applications to feed off the same data feed. for eg. a client using our application can work with multiple TA applications.. like Amibroker, Ninja Trader7, Multicharts, Neuro Shell trader, Metastock, Fibonacci Galactic Trader etc.. all at the same time, on the same PC and off the same data subscription.

(portion removed for clarity)

We are continuously adding more and more TA clients - next we are adding Excel & were hoping to add Sierra charts also to the list. Giving the power to a client to use his data in excel, sierra charts &/ or Amibroker at the same time can indeed be powerful for some.

Our software is an intermediary - yes, but it is actually Smart Cache Database system which stores historical data for all time frames on the local PC itself, reducing the subsequent history request times from the server. Data requested by any one application, once downloaded is available locally for any other application also. However, the Real time feed goes directly to the application, without any intervention from our application.

This in fact is an excellent marketing idea for a software like yours. Clients already using Amibroker or Ninja Trader 7 could add your software to the existing data feed, without any additional data cost and without the requirement for them to jump to a new application, overnight. This could enable them to slowly migrate to your software if they find more value from your application alone.

Documentation is work in progress and we will be able to give it to you only at a much later date.

Also, I appreciate the benefits of the DTC protocol but I am not aware of any other prominent TA application using DTC.

So let me know what you think.

Thanks !

True Data's statements in regards to the benefits of a local client-side server to serve multiple application are noted, they do make sense to us and we can work with what they have but it must provide a proper interface, like IQ Feed and Interactive Brokers do, which it currently does not. So they should develop a DTC Protocol server within their local server which they do not even need to document because the documentation already exists.

Actually, we describe this kind of model here as proposal for an ideal model:

http://www.sierrachart.com/index.php?page=doc/helpdetails76.html#Proposal

Regarding:
but I am not aware of any other prominent TA application using DTC.

We are not going to change things for the better in this industry with that kind of position. Sierra Chart is a leader in this industry and a lot of effort has gone into the development of the DTC Protocol and documenting it, which you do not have to do, and to establish this as a proper and well-organized communication protocol for the industry at least when it comes to the basic communication of market data and trading information. We would hope that you would join us in this effort.

The protocol does not define a single specific encoding but supports multiple encodings including Google protocol buffers and JSON which are widely used.

Being it uses these two widely used encodings, among others, and being that it is nothing more than a common sense well-organized protocol for the communication of market data and trading information, it only makes sense to adopt it rather than using a proprietary interface.

Who in the industry are doing anything like we are doing to establish a quality common communication protocol? Nobody is. We are going to continue to make this effort until we bring about a change.
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-01 23:56:17