req sending queue when disconnected fails to flush properly upon reconnect

[rockymadden]

Expected Behavior

A req socket is created and connected to an agreed upon address, more than one message is sent via send, a matching rep socket is created and bound, req receives all req messages that were in the sending queue on req.

Observed Behavior

A req socket is created and connected to an agreed upon address, more than one message is sent via send, a matching rep socket is created and bound, req receives the last req message.

Code

const nano = require('nanomsg');

const req = nano.socket('req');
const rep = nano.socket('rep');
const addr = 'tcp://127.0.0.1:8888';

req.on('data', b => {
  console.log(`req: ${b.toString()}`);
});

rep.on('data', b => {
  console.log(`rep: ${b.toString()}`);
  rep.send('response')
});

req.connect(addr);
req.send('1');
req.send('2');
req.send('3');

rep.bind(addr);

process.on('SIGINT', () => {
  req.close();
  rep.close();
  process.exit();
});

[deepakprabhakara]

@rockymadden You'll need a queue to overcome this issue. It's one of those quirks of bridging the async world of javascript with the sync world of C. Since a req socket is supposed to operate in the "send -> recv -> send -> recv -> ..." pattern you'll need to buffer your sends until a 'data' event occurs (which signifies the recv event). At the end of the 'data' handler check if your queue has any elements and then call a req.send

[reqshark]

i tend to avoid req/rep and just use pub sub over TCP.

TCP transport at the kernel requires packet ACK (msg recv confirmation) and retransmit, so message loss is nonexistent so long as endpoints have access to the network routing system. And if you're doing inproc or ipc, a req/rep makes even less sense because modern kernels guarantee both order and msg delivery at the machine. that's why UNIX datagrams are my personal fav