Add Multipart Message Support

[joshrtay]

Added Socket#send_mutli and fixed bug in Socket#_flush that occured when a message was received in the middle of send_multi call.

[tj]

could you add a test? I'm not really sold on having a second method for it, plus this is camelcase land :p but yeah we could add variable arg support back to send() perhaps, or just the flag with .send()

[joshrtay]

what do you think?

[tj]

this method is hot so we should make sure to optimize, things like ditching msg.forEach( etc

[joshrtay]

In the current code base multipart send is buggy, so you should probably either implement the emit on nextTick change or the don't flush if sndmore flag change.

The problem is that if you call send('1',zmq.ZMQ_SNDMORE) and then send('2'), the flush from first send may emit a 'message' event and if one of the listeners of the message event calls send then the frames of message are not going to be delivered in the expected order.

[ronkorving]

+1 on fixing this issue. ZeroMQ without multipart is unusable (for me, anyway).

[vvo]

Hello, indeed before near complete rewrite of zmq node we were able to do this :

sock.send('frame1', 'frame2', 'frame3');

and then receive

sock.on('message', function(msgArr) {
console.log(msgArr[0], msgArr[1], msgArr[2]);
});

Breaking this made the module not usable by people using this kind of messages.

+1 so !

[tj]

sorry for the delay :D

[ronkorving]

Thanks, much appreciated!

[joshrtay]

ya - thanks.