DTC Protocol Discussion Forum
- DTC Protocol Discussion Forum |
- Search Board |
- Control Panel |
- View My Posts / Threads |
- Direct Messages
Date/Time: Fri, 29 Nov 2024 16:37:23 +0000
what does SC do with update trade message
View Count: 3974
| [2015-09-18 21:42:01] |
| vbmithr - Posts: 204 |
|
On OKCoin, I use their websocket connection in order to get new trades. The problem is that, in addition of using a very poor precision timestamp (in the form hh:mm:ss), they also send trade updates multiple times. I think the timestamps are reliable though, meaning that if they send two times the same update, it will have the same timestamp. On my charts, I get repeating patterns. So I was wondering if when SC receive a trade update, it actually think that a trade is occuring now. Does it checks the timestamp ? |
| [2015-09-20 01:48:35] |
| |
|
In Sierra Chart, the Update Trade message will update the chart bars. Chart bars just consists of trades only, by default. The timestamp used is what you set into the Update Trade message. Those timestamps need to be in order. If they are slightly out of order like a second, usually that goes unnoticed but it should be avoided. |
| [2015-09-20 10:01:16] |
| vbmithr - Posts: 204 |
|
And what happens if I send an update trade with a timestamp largely out of order, or send multiple update messages for the same trade ?
|
| [2015-09-20 10:10:32] |
| |
|
And what happens if I send an update trade with a timestamp largely out of order It will cause out of order timestamps in the chart. Something like this is not regarded as acceptable and causes various problems. or send multiple update messages for the same trade
Each of these is considered a single and distinct trade.
Date Time Of Last Edit: 2015-09-20 10:11:07
|
| [2015-09-20 10:26:12] |
| vbmithr - Posts: 204 |
|
Because as it stands, for OKCoin, I have historical data that is cleaned because I send DTC users only results from a database that has been cleaned. But I'm using their websocket connection for updates and they frequently send garbage in that (multiple trades, out of order, etc.). Now I have fixed this to be sure to send once and only once every trade. But now I'm not sure with the interaction with historical data prices. What happens if Sierra Chart does an historical prices request, and then after this, an update trade msg is received for a thade that already been pushed through historical order updates? I guess, the same, "each is considered a single and distinct trade". |
| [2015-09-20 12:06:50] |
| |
|
What happens if Sierra Chart does an historical prices request, and then after this, an update trade msg is received for a trade that already been pushed through historical order updates? Do you mean the historical price data? In this case it will be included twice. However, this is not the usual problem. It is the opposite where after a historical price data response, the last historical trade received is lagging behind the real-time data and we have to fill in a few missing trades from the recently received real-time update trade messages. So if the web socket data feed is lagging, then this is a problem. It is possible for us to solve this with a simple flag for the service. Sierra Chart does have that capability. We will do that for your services. Date Time Of Last Edit: 2015-09-20 12:10:23
|
| [2015-09-20 12:16:20] |
| vbmithr - Posts: 204 |
|
From my part, I solved this in filtering the trade updates I send and not sending any trade that has occured before the user connection or historical price data request, whichever is latest. I think this way I pretty much solved the problem. |
| [2015-09-20 12:18:23] |
| vbmithr - Posts: 204 |
|
So, let's reformulate the question: What is the normal procedure of price updates? How do you ensure that there is no clash between the historical price data and the trade updates. Or, how do you ensure that it is never the case that a trade is sent through historical data and from a trade update as well? |
| [2015-09-21 09:44:45] |
| |
|
Or, how do you ensure that it is never the case that a trade is sent through historical data and from a trade update as well?
We think you are probably overthinking this. In the case of Sierra Chart, it is first going to request streaming market data and then after that it will make it historical price data request.It is a normal case where there are Update Trade messages received, that are also received in the historical data during the historical data download. Sierra Chart handles the transition properly. The only real problem is when at the time the last historical price data record is received, that a subsequent Update Trade message contains a trade already received in the historical data. Sierra Chart can filter this out by looking at the timestamps. It is best to handle this on the client-side. When developing a server, it should be building the historical database from the same real-time stream that it is sending to users. In our own server, when we send the final historical data record, it does lag one or two seconds behind the most recent Update Trade message which has been sent. So we do not experience a problem. Date Time Of Last Edit: 2015-09-21 09:45:34
|
| [2015-09-21 11:23:19] |
| vbmithr - Posts: 204 |
|
Ok, thanks for the explanation, this is what I needed.
|
| [2015-09-23 08:04:09] |
| |
|
After contemplating this, we think the DTC historical price data protocol should have a separate trailer message which indicates the end of a stream of historical price data messages and also includes the Date-Time down to the millisecond of the last included trade in the last historical price data message. This will help the client when it is transitioning from historical price data to the real-time data. Date Time Of Last Edit: 2015-09-23 08:05:00
|
| [2015-09-23 08:31:46] |
| vbmithr - Posts: 204 |
|
It would be good that Sierra Chart knows when a trade is a duplicate and reacts to this event accordingly.
|
To post a message in this thread, you need to log in with your Sierra Chart account: