Question

我有一个python程序，它将接受ZeroMQ REQ请求者，并根据给定的代码提供许多功能。

因此，如果客户端发送代码02，python将返回内存统计信息，03 CPU统计信息等等。

使用nodejs和zeromq.js创建客户端，以便与后端进行通信。我不确定从前端发送多条消息的最佳方式是什么，因为我会每秒发送多条不同代码的消息。

我现在拥有的是类似的东西：

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']); 
    });
};

通过调用/workers函数，我可以看到第一个请求到达我的后端，但除非我重新启动整个nodejs应用程序，否则不会再有其他请求到达。

为什么会发生这种情况，并且考虑到我想发送许多消息，是否有更好的方法来构建我的nodejs应用程序，因为我没有在ZeroMQ指南中看到任何类似的示例。

Answer 1

为什么会这样？

ZeroMQ在每个预定义的Formal Scalable Communication Archetypes中使用分布式actor模型进行多方行为。

REQ 只是此类多方分布式行为的一部分。

相反且对称的基数和必要部分是 REP 节点。

这个分布式行为游戏（称为REQ/REP）的完整图片是：

REQ 问，
REP 回复（是的，首先必须接收并确实阅读消息＆amp;然后发送回答），
REQ 只有在.recv()来自REP的{{1}} - ed（未加载）此类答案后，才能再次询问REP得到另一个回复...

这意味着，您的代码必须在内部与此对齐并协调其本地行为，以便满足此distributed-computing行为游戏。

忽略这些硬连线规则意味着一个问题 - 您的 REQ 端代码现在看来，它只是保持在其自锁FSA状态（想要发送下一条消息）），在.recv()的第一个{REP之后REQ方面已经（或将会）到达.send()的第一个和后续的答案。 {1}}，因此REQ永远不会再次（直到重置，如上所述）到.send()任何＆＃34;接下来＆＃34; -message再到{{ 1}} - 部分

。

使用zeromq.js从nodejs应用程序与python后端进行通信

1 个答案:

为什么会这样？