CODEWITHSUNDEEP
javascriptnode.jszeromq
dearn44
dearn44

Reputation: 3432

Using zeromq.js to communicate from a nodejs app with a python backend

I have a python program that will accept a ZeroMQ REQ Requester and provide a number of functionalities, based on the given code.

So if a client sends a code 02, python will return back a memory statistics, 03 a CPU statistics and so on.

The client is created with nodejs and zeromq.js, in order to communicate with the backend. I am not sure what the best way would be to send multiple messages from the frontend, since I will send multiple such messages with different codes each second.

What I have now is something similar to this:

module.exports = function(app) {

    var zmq = require('zeromq')
    , sock = zmq.socket('req');

    var con_string = ''

    app.post('/connect', function(req, res) {
        protocol = 'tcp';
        address = req.body.address;
        port = req.body.port;
        con_string = protocol + '://' + address + ':' + port;
        sock.connect(con_string);
        res.send('OK');
    });

    app.get('/workers', function(req, res) {
        sock.connect(con_string);
        sock.send(['client', 'echo', '02']); 
    });
};

By calling the /workers function I can see the first request arriving at my backend, but no more subsequent requests will arrive unless I restart the whole nodejs application.

Why is this happening, and also given that I want to send many messages, is there a better way of structuring my nodejs app, since I did not see any similar examples available on the ZeroMQ guide.

Upvotes: 1

Views: 613

Answers (1)

user3666197
user3666197

Reputation: 1

Why is this happening?

ZeroMQ uses distributed actors-model for a sort of multi-party behaviour in each of their pre-defined Formal Scalable Communication Archetypes.

The REQ is just a one part of such multi-party distributed-behaviour.

The opposite and symmetrically cardinal and necessary part is the REP node.

The complete picture of this distributed-behavioural game ( called REQ/REP ) is this:

REQ asks,
REP replies ( yes, first has to receive and indeed read the message & then mus send an answer ),
REQ can only, after having .recv()-ed ( un-loaded ) such an answer from REP, go and ask again the REP for getting another reply...

This means, your code has to internally get aligned with this and coordinate it's local behaviour so as to meet this behavioural game.

Ignoring these hardwired rules means a problem -- your REQ-side code n now seems, that it just remains inside its self-locked FSA-state ( wanting to send next messages ), where it simply somehow forgot to also .recv() the first and subsequent answers, that have ( or will have ) arrived from REP-side after the REQ's first .send(), and thus the REQ will never be able again ( until the reset, as was explained above ) to .send() any "next"-message anymore to the REP-part.

Upvotes: 1

Related Questions