Propojeni J Forex Dde Server

Propojeni j forex dde server

DDE- is a possible MetaTrader Terminal integration method,
BUT ...



given that one needs a just one-way direction of the communication and given the business domain is not any mission-critical one.

While I remember days, when interbank Money Markets trading was riding on REUTERS products, with fat add-ons for Excel spreadsheet based "analytics", but it is fair to say, that such days are forever away. Just compare how many trading events were common in those, just interbank-dealing days, prior to full opening of the FOREX trading via proxy-brokerages.

Inter- delays were in minutes, those day.

And today?
If one sources LP-provider data-feeds, there are many units, if not tens of PriceDOMAIN -events with a single millisecond.

Got the point?
DDE is a risky per-se method for a system with event flows
and might be happy to know, it was already effectively discontinued as late as Vista launched

In case one's business-domain is to handle a FOREX trading with an AUM's Value At Risk above a few millions of USD, no one would risk a problem of underperforming or discontinued service.

DDE-based services have ended in the MT4 trading domain somewhere around the Windows Vista were introduced, because it officially but indirectly terminated a use of a mix of those days commonly used DDE-services ( that were formally implemented in wV, but most of the DDE-calls were returning a Error/Response ).

This first hand acquired experience has moved the crowd to some other means of how to integrate Trading Supporting Systems and the designs simply have never returned back for reviving a service, that has caused so much pain and costs, during that nightmare experience in wV.

The Best Next Step:

Supposing an above sketched Project is not a weekend hobby toy, the best sufficiently robust and platform-independet tool for such Project goals is to be defined, found and used.

One may try to revive DDE, but it would be a try to jump a few decades back in time.

In the same manner, one will do one's best by not losing her/his time with re-wrapping any straight app-to-app integration logic into overheads and design/performance compromises/scape-goats of an-artificial-REST-alike re-dressing of the ( very limited ) function calls ( for restrictions of one may check other posts on this subject ).

While there is a chance to use a not only for a , but also a quasi data service, the costs and the http-header + the http-body payload-encoding + the full tcp/ip-stack related overheads are by far un-justifiable for the given purpose, once smarter designed tools are available

A few points for such modern tool-definition:

  • performance scaling ( how stable it is to send 10k, 100k, 1M+ updates/s )
  • integration support ( how many languge-bindings / platforms do support the tool )
  • thread-safe design ( how many threads could be used ( outside the MetaTrader Terminal's restricted code-execution environment's limits ) so as to mitigate any adverse blocking or performance bottlenecks and allow some kind of fail-safe design of the distributed system processing scheme )

If need some hands-on example, one may have a look on and/or ZeroMQ tools, in other MetaTrader Terminal related posts, that have taken over the FINTECH high-performance, scaleable, low-latency messaging/signalling and grew stable/mature-enough to spend a reasonable time with.

Good luck on FX Markets!

Propojeni j forex dde server