I have been working on an algorithm ( Not mine, I am just modifying it ) that predicts when to buy and sell on the FOREX market. I need to be able to open and close orders, dynamically update parameters of the orders ( such as stoploss, maximum stop etc. ) and receive real time tick data.
I have been researching for well over a week, and have no success.
The closest I have gotten is using JavoNet and Mt4 Api
I managed to import the DLL into java and use a MQL4 function, which was AccountBalance(), however this has returned 0.0, which was not the account balance, I messed around with the code and the settings on MT4 client but still no luck.
Q0: Can anyone please point me in the right direction?
I am new to automated FOREX trading but from what I understand there is a broker somewhere with a MT4 server and I connect to that server with my MT4 client on my windows machine.
Q1: If this is the case, do I need to make an API work with the server side instead of my client side?
All these DLL's I have tried so far have been used with the MT4 client software on my machine.
I have also been doing some reading on the FIX-Protocol and ZeroMQ.
Q2: Can these help me achieve my goal in any way (instead of creating some bridges between JAVA and MT4 DLL's)?
A0: yes, forget straight about REST and synchronous, blocking chains in FX-trading domain
A1: well, not a typical way. MetaTrader Server is a proprietary suite of systems on the Broker-side and theirs API are not disclosed to allow some 3rd party integrations against.
A2: FIX-Protocol is the industry standard LP-interfacing lingua franca. In case you have contracted relations with your institutional trading provider, incl. the FIX-Protocol GWY-port, this may provide you an A-level access to the Market and to integrate your trading tools against. If this is the case, forget about MT4 instrumentation, as prime-time cadences are far beyond the MT4 Terminal localhost processing architecture ( multiple events with a sub-millisecond TimeDOMAIN resolution are common, whereas MQL4 does not provide any direct support for multithreaded-concurrent / better parallel programme scheduling designs ). FIX-Protocol events are simply off-the picture above, being far left, "before" the graph starts from 1st [ms] column.
ZeroMQ may help liberate your further designs from MQL4 limitations. May like to read my other posts on distributed systems, where MQL4 / ZeroMQ / ML-AI-predictors / GPU-processing infrastructures appear.
Anyway:
Enjoy the Wild Worlds of MQL4/MQL5
Interested? May also like reading other MQL4, ZeroMQ distributed processing and low-latency trading posts
You can try MetaApi https://metaapi.cloud cloud service which provides REST API and WebSocket API access to both MetaTrader 4 and MetaTrader 5 accounts.
Official REST API documentation: https://metaapi.cloud/docs/client
SDKs: https://metaapi.cloud/sdks (javascript, python and Java SDKs are provided as per April 2021)
It supports reading account information, positions, orders, trade history, receiving quotes, and accessing market data.
The service also provides copy trading API https://metaapi.cloud/docs/copyfactory and API to calculate forex trading metrics on a MetaTrader account https://metaapi.cloud/docs/metastats.
I started to code an expert with MQL5, naturally on MT5 platform, and I must admit that the difficulty of managing the application along with the increase of its complexity is high. It's not only due to a missing garbage collector, that of course imposes the deletion of the new instances, but also because Java offers a set of powerful data structures and syntax that MQL5 naturally doesn't have. Last but not least, talking about the community and the third party libraries available, there's a light year of the distance between Java and MQL5. I.e. if I need to find a library for a JSON conversion on the Java side I find dozens of official and stable versions, in the MQL5 community I have found only rubbish that I had to modify myself.
So, after numerous failed tries on coding my expert in MQL5 (not a simple one of course), I decided to adopt a radical approach: coding an application, client-side MQL5, and server-side Java, that provides a Java facade for the MT5 platform. Same API, same basic events and so on. Even though I thought more than once that I was getting stuck in a blind path, I kept coding and eventually, I made it, obtaining a really solid result.
Naturally, the REST interface drastically reduces the performances, and each request, even with Tomcat and MT5 running in the same localhost, is in the order of milliseconds, not micros, but on the other side this reduces only the suitability of this architecture, it doesn't make it useless at all.
Strategies like scalpelling and every kind of high-frequency trading are not good for such kind of scenario, vice-versa every other strategy in the longer period, even if intraday's ones, can be implemented successfully without any cons.
Last but not least, it isn't necessary to use the WebRequest() MQL5 method to call any Servlet container, it is possible to import the wininet.dll from the OS (talking about Windows) and the strategy tester will work as if the strategy has been coded in MQL5, maybe just a little bit slower.
To sum up, I wouldn't be so sarcastic on the Java facade approach for the FX trading platforms, citing only the nude performances without contextualizing the overall scenario is a naive approach to face the argument.
If you need to send/receive synchronous message between MT4 and Java application, REST would be the best approach because fast response matters in this scenario. Message Queue solutions like ZeroMQ fits better in asynchronous solutions, so it won't help you. Once you choose REST approach, you can use MQL4 WebRequest() to call your Java application.
WebRequest isn't the end of the world, you can submit http requests from your EA using API, works even with Strategy Tester.
In order to collect the tick information and open, update or close orders, you can use mt4 server api.
please check this url.
http://mtapi.online/#overlappable-4
Maybe you will find what you want.
And then I have also mt4 server api. If you have any questions please update me.
I have a question about my system's design. I searched the questions but couldn't find the same situation. So currently I have system that has 1 server and multiple(300+ for now) clients that connects with RMI. Since integrity issues I need to make this system fail safe so I need another server. I don't know how to configure my application for that for now but while doing so I'm wondering that if I could the server side clustered even with load balancing? These two servers are going to be different places with different ip addresses of course and they are comprehensive machines as well.
For example for when a client makes a request it makes the request to more available one.
I searched for external solutions but I'm very new to this stuff. Can you make a suggestion about them as well.
I appriciate the responses. If anything is not clear ask and I will clear it as much as I can.
RMI/JRMP doesn't support that in any way shape or form, but RMI/IIOP with a suitable failover ORB might.
We have some service running on 'n' number of hosts behind a VIP. When there is some fault that occurs with specific request call, we might be interested to know the reason by looking at the logs on the respected host where the fault occurred. since the request could go to any host, when it comes to tracking logs, we need to know from which host the fault originated.
One solution is to store the host name in the database of our service along with other information.
The alternative is, pushing the logs onto a common store and tracing it there.
I personally feel that if we go with the first approach, we might end up in adding many such debugging related attributes in the application database thereby polluting it. However the second option is also not that easy to implement and incurs some overhead. Moreover on which host the fault occurred does not help much except in case the fault occurred due to some hardware specific issue.
What do you guys suggest?
Without knowing more about your infrastructure, it's hard to be precise, but here are some general points of view.
I don't like using databases for storing application logs - if the database falls over, you wouldn't be able to log it! It's also not really relational data, and you can't get the monitoring tools that are available for other solutions.
My recommendation is to use your operating system's built in event logging solution; most logging frameworks support this out of the box. On Windows, that's the event log; on *nix there's the syslog system. Logging should be quick, cheap, and bullet proof - that's what you get from the OS tools.
The second question is then how you use those logs for trouble shooting and monitoring. There are lots of tools for doing this, though mostly aimed at system administrators rather than developers. Microsoft have MoM, there's Tivoli and Big Brother - as well as a whole bunch of open source tools. I'd use those, rather than build your own solution.
The key point is - logging should be fast, cheap and robust; the analysis and monitoring stuff should be entirel separate from your application logic, so you can reuse the tools and processes acros multiple projects.
storing the hostname should be quite cheap I guess. I understand you are appending logs to a db?
you could also store the pid for each process, that can help you in case you have multiple processes running on same hostname. The combination hostname/pid/timestamp will ensure you identify uniquely a process.
I've written a high-throughput server that handles each request in its own thread. For requests coming in it is occasionally necessary to do RPCs to one or more back-ends. These back-end RPCs are handled by a separate queue and thread-pool, which provides some bounding on the number of threads created and the maximum number of connections to the back-end (it does some caching to reuse clients and save the overhead of constantly creating connections). Having done all this, though, I'm beginning to think an event-based architecture would be more efficient.
In searching around I haven't found any equivalents to libevent for Java, but maybe I'm not looking in the right place? Mina-statemachine from Apache was the closest thing I found, but it looks more verbose than I need and there's no real release available.
Any suggestions?
I am a bit late but:
Have you looked at Netty?
Or Grizzly.
How about the Light Weight Event System? :) http://www.lwes.org/ and http://sourceforge.net/projects/lwes/files/
The answer seems to be 'no', though it looks like the Ruby EventMachine library provides a Java implementation for JRuby users that might be usable or at least serve as inspiration for writing my own:
http://github.com/eventmachine/eventmachine/tree/master/java/
You might be looking for a workflow engine like
JBPM or any other open source tool listed here.
In continuation to my question How to improve the performance of client server architecture application
I have decided to maintain a centralized database and several slave server-database configuration. I plan to use Symmetric DS for replicating between the slave and master database. Each server-database configuration would be installed closer to the client. Ideally I want the request from a client to route to the nearest slave server-database for the obvious reason. Since I'm using RMI to connect to the server, I want to know if there is any product/API currently available, which would solve this?
Any other solution than the above one is highly regarded :)
Note: Refactoring the client code is definitely one alternative but since the application is very huge, its a huge risk (can break existing code), time taking & expensive.
Take a look at distributed and consistent hashing:
http://en.wikipedia.org/wiki/Distributed_hash_table#Keyspace_partitioning
http://en.wikipedia.org/wiki/Consistent_hashing
Barebones, you would setup a variant of consistent hashing that would take the identifier of the client (in lieu of the 'key') and locate the nearest server. Bonus benefit here is that if one of the slaves goes down, your infrastructure will transparently route to the next nearest server.