Integration to SierraChart DTC server

Hi, Jcl,

I think it would be a great idea to integrate Zorro with SierraChart (SC).

SC is a very lightweight,fast and well engineered application, has very robust integration to nearly all key brokers and datafeeds (including their own) and can also work as a data/oms server - a single point gateway to all of them.

http://www.sierrachart.com/index.php?page=doc/SupportedDataAndTradingServices.php

http://www.sierrachart.com/index.php?page=doc/Contents.php#ExternalInterfaces

This can be easily achieved via SC's DTC protocol - an improvement on FIX. It is very well documented and well supported by SC.
http://www.dtcprotocol.org/#DTCProjects
https://github.com/DTC-protocol/DTC

Combining all the great scripting and analytical capabilities of Zorro with robust access to data and brokers would be a superb combination, and would likely multiply Zorro's user base 10+x.

You appear to be knowledgeable on how this plugin can be implemented. Did you know that you can get a free Zorro S license if you write the plugin yourself and share it with the community?

I unfortunately do not have first-hand experience writing something like this.
It would take me a lot of time, which I would rather spend on creating systems and getting them to production.

Jcl,

what are your thoughts?

It sounds like a good idea, but I have to look into SierraCharts in detail.

Great!
their FXCM integration is via FIX; Currenex is also available (but not in the public list).

This project is interesting to me for several reasons. I might actually just write it myself.

Let me get my hands dirty, and I'll let you know if I have any updates in the next couple of weeks.

This would be great indeed.
I would do a QA then!

jcl,

This plugin would require a TCP socket. Actually, two sockets, since it’s one for history and one for everything else (I would have to log in separately just to get history ticks).

In you and your company’s experience, is it sufficient to write such a plugin as a blocking client, or is it better to implement asynchronous single threaded or asynchronous multithreaded?

Oh, I suppose it would be easier to write them as two separate plugins anyways, now that Zorro will have the multi-plugin feature.

Sierra Chart Trade and Sierra Chart History, I suppose I can call them.

I think a blocking client is ok, but use some internal counter to make sure that the blocking time is limited.

That makes sense. I'll add a timeout feature.

Side note: I do need heartbeats on the main server. History is different - you log in, get ticks, log out.

I’ll start with blocking and see if it runs smoothly enough. Thanks.

OK, it's not nothing. I'll have a beer now.

Cool:-)

Just an update - although DTC protocol supports options, Sierra Chart's DTC server does not sufficiently support options - nor do the developers plan on adding support for DTC options. You can manually punch in an options Asset and trade it, but you cannot get a list of options securities by an underlying (message response: "not supported").

Sierra Chart's developers will soon add the ability to get futures contracts by underlying, so at least we will be able to trade futures.

Ughh!

I hope it is possible to retrieve an option's price, send an order,etc for a correctly formed option's symbol string?

Yes. I suppose one thing you can do is develop your own options asset name string generator, and check if the asset exists by attempting to subscribe to it. Some trial and error may be required.

This project is on hold until Sierra Chart implements listing futures symbols by underlying.

(Per my request, it is on their to-do list.)

This project is back on. But it is still impossible to use GET_FUTURES or GET_OPTIONS.

I will provide a workaround that lets a user directly check for the definition of any given symbol.

Most importantly, it will support SET_HWND, so market messages will update Zorro upon arrival.

The beta and the latest build is here:

https://github.com/AndrewAMD/SierraChartZorroPlugin

Formal announcement to follow in a separate thread.

Thanks,
Andrew