what is sequence of events when [amongst others] ERR_NO_CONNECTION ?

 
I thought I had this straight in my head, but constant looking at the logic/flow + decisions made, seem leaky as a paper hulled ship!
.
When the line goes down AND no data ticks incoming I assume start() never called - Y/N ?
.
Should start() be executing when server down event occurs AND IsConnected() is false I assume this is the one chance for EA to take actions regards current market orders - Y/N ?
.
Above seems flawed to me. ie, if only one chance to 'do something' then with a glitchy line this seems inappropriate to keep reacting at each server down event.
.
Why all this?
At start() top, code checks for current Client environment status and the EA reacts accordingly. eg, if(!IsExpertEnabled()) then lets do any generic management and then return().
Why EA is not enabled especially when their are market orders - this would seem a faulty action for gui to do... but maybe that's it's lookout and basically tough luck if money is lost due to lack of trade management.
Are various statuses: stopped, enabled, connected, weekend, fridayTrading,..
IE,
what part and how much of: one or more EA functionalities should be done for each status ?
what can be done ie, is start() called none, one or many times ?
.
damn, getting knotted up/unsure as to what should be thinking about and how to design it (a true duh timeframe ;) and really need some inputs if you'd be so inclined!
.
Thanks
 
fbj:
When the line goes down AND no data ticks incoming I assume start() never called - Y/N ?

It won't be called until next incoming tick of Symbol().

Should start() be executing when server down event occurs AND IsConnected() is false I assume this is the one chance for EA to take actions regards current market orders - Y/N ?

Yes. But if IsConnected()==false, then u can't do much, can u?

Above seems flawed to me. ie, if only one chance to 'do something' then with a glitchy line this seems inappropriate to keep reacting at each server down event.

You are likely to not have a chance at all. From experience, unless start() is extremely slow (many calculations...) then it is most likely that line would fall BETWEEN start() calls, hence it would never even have a chance to 'see' IsConnected()==false.


From my experience and IMHO, the number one thing to do in order to avoid all these problems is to move your trading to a server/VPS at a reliable hosting company. For the past 8 months I have been trading from a dedicated server with up to 8 Terminals online simultaneously (connected to multiple brokers) and I have never had disconnections that lasted more than 2-3 minutes (and all those were verified to be the broker's fault - usually during 'news').

 
gordon:

From my experience and IMHO, the number one thing to do in order to avoid all these problems is to move your trading to a server/VPS at a reliable hosting company. For the past 8 months I have been trading from a dedicated server with up to 8 Terminals online simultaneously (connected to multiple brokers) and I have never had disconnections that lasted more than 2-3 minutes (and all those were verified to be the broker's fault - usually during 'news').

It varies by broker and the server farm which you're connected to. And other factors as well. For example, without apportioning blame or implying that they're any worse than anyone else, we went through several weeks of having 2 live Alpari UK accounts which repeatedly went down. There were 4 other Alpari accounts, and all 6 were configured identically. But there were 2 in particular which kept experiencing problems. Similar sorts of occasional anomaly on other brokers.

gordon wrote >>
I have never had disconnections that lasted more than 2-3 minutes

Out of interest, how do you know?

 
jjc:

It varies by broker and the server farm which you're connected to. And other factors as well. For example, without apportioning blame or implying that they're any worse than anyone else, we went through several weeks of having 2 live Alpari UK accounts which repeatedly went down. There were 4 other Alpari accounts, and all 6 were configured identically. But there were 2 in particular which kept experiencing problems. Similar sorts of occasional anomaly on other brokers.

I meant relative to the average home connection... BTW, my server is in the UK, I trade with a UK based broker but also with RU and US based brokers (their servers are in Moscow and NY) and there are no problems. Rock solid connection for about 8 months now.

Out of interest, how do you know?
I have a simple EA running in a loop and logging IsConnected() status to file. I do this for each Terminal. Have always done so.

Edit: I use something very similar to this one -> https://www.mql5.com/en/code/7744.
 
gordon:
Yes. But if IsConnected()==false, then u can't do much, can u?

true, was thinking along lines of noting the event. There is the scenario where order sent -> server gets -> line down -> cannot reply -> client times out eventually. Pool ticket #'s can change due to new order resulting from part close, pool must be inspected to find (via magic) - all that sort of stuff.

Here is where I think docs are misleading since as you rightly say, no ticks=no start() entry, yet for me at least, the docs just skate around the fact that start() never called so investigations is not done...

You are likely to not have a chance at all. From experience, unless start() is extremely slow (many calculations...) then it is most likely that line would fall BETWEEN start() calls, hence it would never even have a chance to 'see' IsConnected()==false.

guess saying that IsConnected() is not actually very useful unless on that atypical instance where it is caught. Your obs would not support this tho.


From my experience and IMHO, the number one thing to do in order to avoid all these problems is to move your trading to a server/VPS at a reliable hosting company. For the past 8 months I have been trading from a dedicated server with up to 8 Terminals online simultaneously (connected to multiple brokers) and I have never had disconnections that lasted more than 2-3 minutes (and all those were verified to be the broker's fault - usually during 'news').

No can do = I use stops (always and not those unreal zillion pt one either :) and the strategies used basically live with it. Is not ideal of course but there it is = am not big institutional trader/coder nor have the setup that I'd allow to freewheel 24/7

So in reality, it is that my ruminations are futile. I will take the path of not being called and just get on with the show when [eventually] called. Although, maybe EA could take note [on exit] of clock time and on recall, use the last exit time as part of method to do something dependant on its current trading state...

Thank you Gordon for your comments


jjc, your observations and experiences most appreciated too!

How lucky? am I to be with Alpari UK...


 
fbj:

So in reality, it is that my ruminations are futile. I will take the path of not being called and just get on with the show when [eventually] called. Although, maybe EA could take note [on exit] of clock time and on recall, use the last exit time as part of method to do something dependant on its current trading state...

But what happens if the disconnection becomes permanent and does not restore itself (this happened to me in the past when trading from home -> https://www.mql5.com/en/forum/118546). A possible solution would be to have a secondary EA running in a loop at init() (in the same Terminal) checking for IsConnected() and performing certain tasks if connection falls for longer than a predefined period of time:
  1. Alert the user using an Alarm, email, SMS, Skype, etc. (some of these would only work if internet is still up).
  2. Have the EA 'talk' to a secondary computer occasionally; the secondary computer alerts the user if no messages come in for a predefined period of time.
  3. Attempt restoring the connection using a simulated re-login (via WinAPI calls) or using a method as described here -> https://www.mql5.com/en/forum/123488.
Any other ideas?
 
gordon:
But what happens if the disconnection becomes permanent and does not restore itself (this happened to me in the past when trading from home -> https://www.mql5.com/en/forum/118546). A possible solution would be to have a secondary EA running in a loop at init() (in the same Terminal) checking for IsConnected() and performing certain tasks if connection falls for longer than a predefined period of time:
  1. Alert the user using an Alarm, email, SMS, Skype, etc. (some of these would only work if internet is still up).
  2. Have the EA 'talk' to a secondary computer occasionally; the secondary computer alerts the user if no messages come in for a predefined period of time.
  3. Attempt restoring the connection using a simulated re-login (via WinAPI calls) or using a method as described here -> https://www.mql5.com/en/forum/123488.
Any other ideas?

naw, ya got me there. #3 seems clean/killer way to do. I had thought about just stay in start() using refresh and sleep - for a bar based system, this would I'd imagine be like #2 in that one EA does it all - to incl. #3. But looping seems not good/not what Client environment is all about...

#1 is food for thought - especially given wireless comms/devices these days. Think I'm envisaging copper/cable and wireless alternatives. Seems complicated tho.

Course, would need to gear up by many notches, my C/WinApi skill set. On the other hand, being a Luddite, WindApi + assembler is more attractive but again, beyond understanding the higher levels/concepts of what jjc outlined, I'd spend much time playing to 'get it right'. Time is not on my side... This issue of stop -> restart to untangle client/server is veeeery interesting development which makes my "oh well, just take the losses etc", a bit cavalier ;)
Seems to me that the issue always comes back to the K.I.S.S. domain. Whenever I think too much about all this stuff and [of course] get all this great info from the collective luminaries herein - one just get's overwhelmed with 'stuff' one could possibly do. So ok Gordon, best bet [sometime] is to VPS it with the proviso, that having learned what could/has gone wrong with server connections, I'd still feel obliged to cater for the those worst cases ;)
Reason: