1

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?

Improve this question

1 Answer 1

Reset to default
1

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.