I am trying to see whether it is feasible to build a custom indicator for MetaTrader that can make asynchronous internet requests, in order to post data to a server with a PHP interface.
These requests might take some time for the webserver to process, so I am worried that they will block the indicator from continuously updating new tick data if they are performed in a synchronous manner.
Are there any asynchronous libraries available for MT4?
Yes, there are
MT4 can directly use ready-made bindings for great platform-to-platform & process-to-process messaging library, be it
ZeroMQ
ornanomsg
.Having used the former for several years,
MQL4
processes can form a non-synchronised ( i.e. independently of aaMarketEVENT
arrival a.k.a.quote
, or less exact called also a "tick
" )ExpertAdvisor
->script
orscript
->script
inter-process communication solutions, that allow to build a powerful augmented GUI services for professional trading and many other features for soft real-time systems & low intensity HFT clustering.On the other hand, one may equip
MT4 EA
with a few indispensable services with this same messaging technology platform:keyboard
for a CLI alike interface to the running EAfile-IO
for the HFT servicessyslog
service for the ( non-blocking ) loggingGPU-based
AI/ML real-time models for advanced tradingNota bene
From the design/architecture point of view, an
MT4
indicator thread has certain limitations one shall be aware of.An otherwise common
POST
-based publication to aphp
-process on a remote WebServer will definitely take much more than a few tens of milliseconds, that are causing an un-avoidable issue for the above asked formal achitecture.One shall rather minimise all
MT4.CustomIndicator
-embedded part of the processing, so as to avoid the processing to slip behind the nextaMarketEVENT
arrival, thus to prevent a skew in synchronicity of calculated values.This can be achieved by dispatching all the non-core functionalities "outside" of the scope of the
MT4.CustomIndicator
code ( usingZeroMQ
process-to-process communication framework ) and solve all the rest of the logic in a different thread, outside of theMT4
. The postprocessing is the least of the issue, the handshaking and values' update & retransmit logic are the focal point of the off-loading from the very fragile thread-synchronicity of theMT4
( one may have observed this issue to become more and more dangerous in recent Builds. Many robust augmented GUI solutions start to suffer from choppy responsiveness in Builds post 7xx and required slight adaptation of their core real-time control loops to regain their UI-robustness and their smooth UI-responsivness under heavy loads )