I just want to send a message from MetaTrader Terminal, using it`s MQL4/5 to Python, just a simple client server, in which MQL4/5 is a client that sends, and python is a server who receives and these two are syncing with ZeroMQ.
The Python side code is this which I am sure this part is working fine:
import zmq
import time
context = zmq.Context()
socket = context.socket(zmq.REP)
socket.bind("tcp://127.0.0.1:9999")
print("Server Started")
while True:
message = socket.recv() # Wait for next request from client
print("Received request: ", message)
time.sleep (1)
socket.send_string("World")
the MQL4/5 side is this:
Context context( "helloworld" );
Socket socket( context, ZMQ_REQ );
Print( "Connecting to hello world server…" );
socket.connect( "tcp://127.0.0.1:9999" );
while ( True )
{
ZmqMsg request( "Hello" );
socket.send( request );
ZmqMsg reply;
socket.recv( reply ); // Get the reply.
Sleep( 1000 );
}
it seems like MQL4/5 doesn't send anything.
Can you say what is wrong with it?
Can you say what is wrong with it?
A few things to start with on MQL4/5-side :
MetaTrader Terminal can operate the compiled MQL4/5 language in several, quite different code-execution modes.
If this was tried in Script, the damages are less cardinal than if this would be in ExpertAdvisor and worst side-effects would happen if this was run in some CustomIndicator -type-of-MQL4/5-code.
On ZeroMQ-side :
In any case, REQ/REP Built-in Scalable Formal Communication Archetype pattern is a worst case choice, as in many previous posts, there has been explained how fragile this built-in was and that it can easily fall into a principally un-salvageable mutual dead-lock juxtaposition, so better re-read these posts and try to avoid this risk before going into production-grade service desing and implementation.
Always setup socket.setsockopt( zmq.LINGER, 0 ), both on MQL4/5 and Python sides. No exceptions, no excuse.
A setup with socket.setsockopt( zmq.COMPLETE, 1 ), both on MQL4/5 and Python sides is also more than adviseable.
ZeroMQ language-specific bindings for MQL4/5 :
As there are several active bindings available for MQL4/5 #import-ed mediations between MetaTrader Terminal MQL4/5 code-execution ecosystem and the ZeroMQ API v.X.Y.Z DLL-library, there is not possible ATM to go into more details. Having used API v2.1.11 ( I had modified the .MQH-file for solving #import-ed interface incompatibilities introduced into the game with New-MQL4.56789 changed game - as string actually stopped being a string and some others ) and having seen other bindings, up to the ZeroMQ API v.4.2.+, there are differences to know about in detail, if going beyond a just "Helloworld"-example.
Yet, Context() instance initiation ought be equipped with appropriate settings / parameters and when testing, your code should routinely acquire all return-codes + handle all exceptions programmatically ( at least Print() them into log for further debugging with FILE and LINE ).
Also use #import-ed function int aZmqERROR = zmq_errno();, wherever your doubts may spring out, so as to know there was no ZeroMQ error state related right before / after a call took place, or to know exactly what was ZeroMQ signalling from its internal layers, that may have prevented an API call to deliver an expected functional state / result. An MQL4/5-side string Zmq::errorMessage( int error ) is ready to advice on some more human readable hints on observing any such ZeroMQ-side error-flag.
Last, but not least :
also check the localhost FireWall-configuration, if the TCP port# == 9999 was actually free to be used, or if the administrative bans on the FireWall security policies did actually prevent any attempt from successfully going and use this port#.
Until validated in public, better terminate each Context()-instance explicitly and with due care ( after having explicitly .close()-ed all locally created ZeroMQ-Socket()-instances. Nasty things could have happended in the earlier API versions, so better be systematic and defensive in all newer API-versions, even if examples or posted code does not do this systematically.
