Reliably detecting connection and history updated

Back to topics list To post a new topic, please log in or register
avatar
735
honest_knave 2016.02.02 14:32
 

Over time, I've experimented with several techniques to reliably and quickly detect whether the terminal is connected and history updated, but they all fall short under certain circumstances.

I'm specifically talking about 2 scenarios:

1. Disconnect/Reconnect with the Terminal running

2. Terminal has just been started

Methods I've experimented with are:

  • IsConnected()
  • iBarShift(exact) on TimeCurrent 
  • Comparing TimeMinute() of TimeCurrent() to TimeLocal() 
  • Comparing time difference between the Time[0] and Time[1]
  • Just guessing a time delay after connection

Does anybody have a reliable method they'd care to share, or any experiences with this they'd like to discuss?

Many thanks in advance 

 

avatar
1109
Ovo 2016.02.02 14:52 #
 

Could you define, how long the disconnection is for you? I mean if you are catching a single tick, or delayed or so, as it may limit means. For myself, I consider there was a disconnection when there was completely missing M1 candle, which suddenly arrived. So it is obvious how I detect it.

But no idea how to reliably detect if the history was completely updated.

avatar
2017
gooly 2016.02.02 14:59 #
 

You can't use OnTick() but using OnTimer() on a high frequency might slowdown the whole system?

But then you have the problem to distinguish between calm markets (no ticks even for minutes) and a disconnect.

For this may be MarketInfo(Symbol(),MODE_TICKVALUE) might be better then time (tick) depending requests.

It should be actual or something like undefined.


avatar
735
honest_knave 2016.02.02 15:03 #
 

Thanks Ovo. So if I understand correctly, you run everything off candle time looking for more than 60 seconds between consecutive candles == reconnected.

The history problem is frustrating because I get inconsistent behaviour with all the methods. Sometimes it catches it, sometimes it doesn't. 

 

 

 

avatar
735
honest_knave 2016.02.02 15:07 #
 
Thanks Gooly - I do use OnTimer() because it can catch IsConnected() and changes in TimeCurrent() quicker than waiting for the next tick to come in. But it still has delays. Overheads are quite light provided the code in OnTimer is basic.
avatar
1109
Ovo 2016.02.02 15:26 #
 
honest_knave:

Thanks Ovo. So if I understand correctly, you run everything off candle time looking for more than 60 seconds between consecutive candles == reconnected.

The history problem is frustrating because I get inconsistent behaviour with all the methods. Sometimes it catches it, sometimes it doesn't. 

 

 

 

Exactly, when the candle at index 1 suddenly appears at index three or more, that is a disconnection for me.
avatar
125
zirkoner 2016.02.03 17:24 #
 
avatar
2017
gooly 2016.02.03 17:51 #
 
honest_knave:
Thanks Gooly - I do use OnTimer() because it can catch IsConnected() and changes in TimeCurrent() quicker than waiting for the next tick to come in. But it still has delays. Overheads are quite light provided the code in OnTimer is basic.
Are you sure that TimeCurrent() becomes - what invalid(?) - if the connection is interrupted. It is always the time of the most recent tick. And if there is no new tick by what ever reason.... ?
avatar
735
honest_knave 2016.02.03 23:15 #
 

One of the problems is that after reconnection, IsConnected==true before TimeCurrent() updates.

void OnTimer()
  {
   if(IsConnected()) { Print(TimeCurrent()); }
  }

 This isn't the best example, as there was only a 1 second delay. But I've seen longer:

 

 

The point being, a reconnection was lodged without any update to TimeCurrent()... 

avatar
735
honest_knave 2016.02.03 23:16 #
 
zirkoner:
Maybe that helps.
Thanks zirkoner - I hadn't seen that before.
Back to topics list  

To add comments, please log in or register