Issue with MQL5 Cloud connection - page 2

[Stefan Anthony Douglas]

as of 29-10-2025 of i have no connection to  MQL5 Cloud Network of distributed computing on any of my computers 

[Emerson Gomes]

It's down for almost a week! A moderator mentioned it was reported, but I am not so sure MQ is aware/actively working on this.

[Alain Verleyen]

Emerson Gomes #:

It's down for almost a week! A moderator mentioned it was reported, but I am not so sure MQ is aware/actively working on this.

What do you want to be sure ? 

MQ is aware about it. 

[Emerson Gomes]

Alain Verleyen #:

What do you want to be sure ? 

MQ is aware about it. 

Thanks. A production server being offline for a week could mean that they are not aware.

[Emerson Gomes]

I have found a workaround.

Shutdown all agents.

Set the content of the reg key "HKEY_USERS\S-1-5-18\Software\MetaQuotes Software\Cloud.Ping" to a empty string.

Re-start the agents.

This key caches the ping times, and doing that will force the agent to perform a new probe.

[Fernando Cavalcanti Martini Teixeira Dos Santos]

Emerson Gomes #:

I have found a workaround.

Shutdown all agents.

Set the content of the reg key "HKEY_USERS\S-1-5-18\Software\MetaQuotes Software\Cloud.Ping" to a empty string.

Re-start the agents.

This key caches the ping times, and doing that will force the agent to perform a new probe.

That works! Thank you.

[dglslu Louis]

Emerson Gomes #:

I have found a workaround.

Shutdown all agents.

Set the content of the reg key "HKEY_USERS\S-1-5-18\Software\MetaQuotes Software\Cloud.Ping" to a empty string.

Re-start the agents.

This key caches the ping times, and doing that will force the agent to perform a new probe.

Definitely works, they say connected now.

[Shalem Loritsch]

Alain Verleyen #:
Reported to MQ attention.

Thank you.  They just released a beta version, build 5395 that "fixes" the issue of MetaTester getting stuck on a server that's down and being unable to correct itself.  However, it's an imperfect fix: Despite still having and checking the cache, the cache is no longer functional due to the new "fix".  The cache was a good idea, just inadequately implemented.  What they need to do now (to make it better than it ever was) is add another value, let's say "Cloud.Sweep" (next to the existing "Cloud.Ping" value) which would hold a timestamp of some sort (e.g. a Unix timestamp, Windows filetime, or even just a date or the day number).  When an agent starts, the first thing it should do is check this timestamp.

1. If the timestamp is recent (say, within 24hrs, or the same day, or perhaps up to a week), the agent should read the cached ping values and skip the ping sequence entirely, directly connecting to the best server in the lineup and authorizing.  If this connection cannot be established (socket fails due to timeout during the SYN_SENT/connecting phase), the agent should set the timestamp to 0 and initiate the ping sequence, update the ping cache and timestamp, and connect to the best server it found.
2. If the timestamp is old, the agent should set the timestamp to 0, initiate the ping sequence, update the ping cache and timestamp, and connect to the best server it found.
3. If the timestamp is 0, the agent should immediately pause for 3 minutes, and then check again (some other agent is running the ping sequence and we want to wait for its results instead of running another one in parallel).  If the timestamp has been updated after the 3 minutes, read the cached values and directly connect to the best server in the lineup (no ping sequence).  If the timestamp is still 0, proceed to the ping sequence, update the ping cache and timestamp, and connect to the best server it found.

Here's the problem that's happening: Every time any agent starts (or decides to rescan), it runs the ping sequence again—oftentimes while other agents are also running the ping sequence, or even if the ping cache was just updated moments ago.  This not only makes agents take a needlessly long time to initialize/connect, but also cranks through (wastes!) ephemeral ports (client and server-side) since the ping is done over TCP connections that are repeatedly opened and closed.  Not a big deal if a single agent does it once a day, but if one has say 16 agents on an AMD 5950X CPU, and several PCs on their network, the current behavior cranks through hundreds of ephemeral ports quickly (each agent wastes 3 ephemeral ports server-side and 18 ephemeral ports provider-side per ping sequence), which can quickly run through the per-user allotment on any Internet service behind a CGNAT (which some ISPs use due to the lack of available public IPv4 addresses).  Even worse for MetaQuotes server-side, this is happening on a massive scale, since all your clients and agents are sharing the same few server IPs, each with maybe 30,000 ephemeral ports available—which are typically reserved for a whopping 4 minutes after each connection has closed.  When these are used up, existing connections that have been open longer suddenly start getting dropped by routers/hops along the way, resulting in broken/unresponsive TCP sockets, leading to repeated agent connect/disconnect events—cycling through even more ephemeral ports and causing network instability.

By implementing the ping caching mechanism as described above, this unwanted behavior would be greatly reduced, resulting in a better experience for everyone.  If you could pass the above on to the development team for consideration, that would be appreciated!