getting double message callback on BUS socket about node-nanomsg HOT 10 CLOSED

indeed, if I run the test case:

var nano = require('./lib/index.js');
var argv = process.argv;

var bus = nano.socket('bus');

var addr = 'ipc:///tmp/' + argv[2];
var p1 = 'ipc:///tmp/' + argv[3];

console.log('binding to', addr);
bus.bind(addr);

console.log('connecting to', p1);
bus.connect(p1);

bus.on('message', function (buf) {
  console.log('received message');
  console.log(buf.toString());
});

var seq = 0;
setInterval(function () {
  seq++;
  console.log('sending...', seq);
  bus.send(argv[2] + " " + seq);
}, 5000);

node test.js n0 n1 and node test.js n1 n0 I do receive the message twice! We will have to figure out if we're sending twice, or firing onmessage twice.

from node-nanomsg.

Looks more like a double receive than double send. Still digging.

from node-nanomsg.

We only set the callback to lib uv once, but it seems to be firing twice, with the same callback.

I wonder if there's some low level incompatibility with nanomsg bus sockets and lib uv?

I get the feeling that whatever libuv does to get notifications, might be getting notified twice for nanomsg bus sockets which would be a bug in nanomsg (or libuv). Writing a test case now.

from node-nanomsg.

I think this is an extension of #10 and #11. With bus, you should only have one process bind, and the rest connect, and they can still send each other messages. When each process binds and connects, then this problem arises. We can't differentiate the socket being marked readable twice from this vs receiving two different messages. A bus socket can send and receive by simply calling bind or receive. You don't relink them twice. For instance, socketA and socketB only share one bind/connect on an address; what you're doing is creating two bind/connect pairs, which is messing everything up (and by #10 and #11 we don't error out at the calls to bind).

For example:

var nano = require('../');
var bus1 = nano.socket('bus');
var bus2 = nano.socket('bus');

var addr1 = 'tcp://127.0.0.1:3000'
var addr2 = 'tcp://127.0.0.1:4000'

// Try commenting these in and rerunning for some fun!
//bus1.bind(addr1);
bus2.bind(addr2);

bus1.connect(addr2);
//bus2.connect(addr1);

bus1.on('message', function (buf) {
  console.log('received message');
  bus1.send('hello');
});

bus2.on('message', function (buf) {
  console.log('hey, I can receive without binding');
});

bus2.send('o hai');

from node-nanomsg.

So in a sense, we're working correctly; we call our onmessage callback twice, since a call to send on a BUS socket that is both bound and connected to another BUS socket is technically notifying the receiver on two addresses. For a BUS socket, the binder and the connector are irrelevant, and each pair should ever be bound/connected via one address, otherwise you can expect onmessage to be invoked once for each address they share.

from node-nanomsg.

Hello Nick! For the first i want to say thank you for your library! However, i have a two issues to talk about, the first its according to this conversation, i'm sure that implementation of "bus" pattern is not correct, and its shouldn't fired up same event twice in that and any other case, because its one of "original" tasks for message queue service. (http://tim.dysinger.net/posts/2013-09-16-getting-started-with-nanomsg.html - last case show how it should be works). I want to help fix that, but its bring us to next issue. You library have a C++ abstraction binding inside and js interface have binding to it - what the reason for this method? May be it can be easy with binding to original (on pure C) library?

from node-nanomsg.

#38 (comment) - at this example missed sockets topology

from node-nanomsg.

i'm sure that implementation of "bus" pattern is not correct

bus is implemented correctly. scroll to the bottom of the getting started link you reference to see dups

a C++ abstraction binding inside and js interface have binding to it - what the reason for this method? May be it can be easy with binding to original (on pure C) library?

we do native abstraction this way to switch data back and forth between V8 JavaScript and C.

from node-nanomsg.

I want to help fix that

Cool, if you spot something wrong, we're always happy to review patches.

what the reason for this method?

v8 does not expose a C API. nanomsg and v8 can only be tied together through C++ (or maybe now Rust) since v8's functions which we NEED for converting JS types to C types have C++ linkage and a C++ ABI.

from node-nanomsg.

yea it'd be nice if we didnt have to use C++.

You know... in addition to Rust, we could've also used https://github.com/node-ffi/node-ffi, but early on when i just started running some experiments and tests on a similar binding for iojs and trying find the best way to write this, I ran a series of performance tests with node-ffi and found that each call carried a higher overhead than calls made with NAN... so that's i went with NAN at the time. Also that was about a year ago so maybe things are different now.

from node-nanomsg.