Posted: Dec 10, 2007 @ 05:54 PM             Msg. 1 of 14

Are you repeating or playing back data on your simulation server? As you can see from this chart image, the data repeats twice clearly in one spot, and repeats in other spots. This creates problems with our data collection.
http://images.sierrachart.com/upload_2/1197327065_7_UploadImage.png

Anthony

Posted: Dec 10, 2007 @ 08:13 PM             Msg. 2 of 14

I think I may have noticed something that might be causing this issue. It may or may not be the cause of the issue in the first post, but this is still an issue I need to resolve.

It looks like when I receive historical tick data, I now receive multiple callback to OnTicksReceived where as before I only received one callback. Our program was expecting to receive only one callback for historical ticks per request, and then anything following it would be considered real-time data. However now, all the remaining historical data after the first callback is now being considered real-time data.

Can you confirm that this is a change you made? I haven't found any documentation or release notes related to this (or any other changes made in the latest version).

Also, is there any way for me to distinguish between historical tick data and real-time tick data now?

Thank you.

Posted: Dec 11, 2007 @ 08:43 AM             Msg. 3 of 14

large amounts of ticks/bars are now split by packets, so client application need to handle multiple callbacks and combine incoming data.

realtime updates usually are coming by 1 tick per update event.

Posted: Dec 11, 2007 @ 01:36 PM             Msg. 4 of 14

Actually I realized that I keep track of the historical tick response by the subscription ID. But what I really need is some way of knowing that I've received all the tick history that I'm going to get. Since there are now multiple callbacks, I need to know which one is the last one. Otherwise I'll be waiting indefinitely for the history to finish before I can switch over to real-time data.

Posted: Dec 11, 2007 @ 01:40 PM             Msg. 5 of 14

there is no indication of "last" packet.
However, by using SubscribeTicks you will get historical ticks and then following real-time ticks in one subscription.

Posted: Dec 11, 2007 @ 02:16 PM             Msg. 6 of 14

How does SubscribeTicks work if it gets called more than once on a contract? For example, if I use SubscribeTicks once to get history and start tick updates, and then I use it again because I want to get history again for the same contract in the same session? Will it cancel the previous subscription, or will I start getting double real-time ticks?

Our program requires knowing when we have completed receiving historical data. If you do not give any notification of when you have sent all the historical tick data that I requested, I will either need to find some (probably less reliable) way of determining that I have gotten all the history I am going to get, or I will have to drop support for your tick history. I can't waste much time on this because the change has already affected our users.

When you split the data, is there a specific size you split it to that I can compare to, and assume the last packet will be smaller than that?

Posted: Dec 11, 2007 @ 02:31 PM             Msg. 7 of 14

if you call subscribe ticks twice, you will get historical data and real-time twice in two different subscriptions.

the block size is currently 4096 ticks, but there is no guarantee that last packet could not be exactly 4096 ticks.

you can check the last timestamp to be near to current time or use a timeout.

also if you are getting 1-tick updates with current timestamp- you can say they are realtime updates, so historical data finished.

Posted: Dec 11, 2007 @ 03:11 PM             Msg. 8 of 14

How soon do you think you could make changes to indicate when a RequestsTicks response has finished sending back historical data? I imagine releasing a new version would be a lot of work for that one change, but if you could do something on the server side such as simply sending a response of 0 ticks to indicate that's the end of the data, I could use that.

Posted: Dec 11, 2007 @ 05:21 PM             Msg. 9 of 14

now tick/bar responses are followed by empty response, even if no data was available.

this change was applied to api.openecry.com server only - please test and confirm whether it works for you.

Posted: Dec 11, 2007 @ 06:25 PM             Msg. 10 of 14

I tested it and that works well. Thank you.

Posted: Dec 13, 2007 @ 01:42 PM             Msg. 11 of 14

I noticed this change was made on the sim server as well. Can you confirm that you've made this change to send an empty response at the end of the historical data on all your servers now?

Posted: Dec 13, 2007 @ 01:57 PM             Msg. 12 of 14

it will be applied to production server today at 5:30 EST.
Edited by SergeK on Dec 13, 2007 at 02:08 PM

Posted: Dec 13, 2007 @ 05:04 PM             Msg. 13 of 14

Thank you very much.

Posted: Dec 14, 2007 @ 01:47 PM             Msg. 14 of 14

You are welcome