What's the most efficient node.js inter-process communication library/method?

If you want to send messages from one machine to another and do not care about callbacks then Redis pub/sub is the best solution. It's really easy to implement and Redis is really fast.

First you have to install Redis on one of your machines.

Its really easy to connect to Redis:

var client = require('redis').createClient(redis_port, redis_host);

But do not forget about opening Redis port in your firewall!

Then you have to subscribe each machine to some channel:

client.on('ready', function() {  return client.subscribe('your_namespace:machine_name');});client.on('message', function(channel, json_message) {  var message;  message = JSON.parse(message);  // do whatever you vant with the message});

You may skip your_namespace and use global namespace, but you will regret it sooner or later.

It's really easy to send messages, too:

var send_message = function(machine_name, message) {  return client.publish("your_namespace:" + machine_name, JSON.stringify(message));};

If you want to send different kinds of messages, you can use pmessages instead of messages:

client.on('ready', function() {  return client.psubscribe('your_namespace:machine_name:*');});client.on('pmessage', function(pattern, channel, json_message) {  // pattern === 'your_namespace:machine_name:*'  // channel === 'your_namespace:machine_name:'+message_type  var message = JSON.parse(message);  var message_type = channel.split(':')[2];  // do whatever you want with the message and message_type});send_message = function(machine_name, message_type, message) {  return client.publish([    'your_namespace',    machine_name,    message_type  ].join(':'), JSON.stringify(message));};

The best practice is to name your processes (or machines) by their functionality (e.g. 'send_email'). In that case process (or machine) may be subscribed to more than one channel if it implements more than one functionality.

Actually, it's possible to build a bi-directional communication using redis. But it's more tricky since it would require to add unique callback channel name to each message in order to receive callback without losing context.

So, my conclusion is this: Use Redis if you need "send and forget" communication, investigate another solutions if you need full-fledged bi-directional communication.

Why not use ZeroMQ/0mq for IPC? Redis (a database) is over-kill for doing something as simple as IPC.

Quoting the guide:

ØMQ (ZeroMQ, 0MQ, zmq) looks like an embeddable networking library but acts like a concurrency framework. It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP, and multicast. You can connect sockets N-to-N with patterns like fanout, pub-sub, task distribution, and request-reply. It's fast enough to be the fabric for clustered products. Its asynchronous I/O model gives you scalable multicore applications, built as asynchronous message-processing tasks.

The advantage of using 0MQ (or even vanilla sockets via net library in Node core, minus all the features provided by a 0MQ socket) is that there is no master process. Its broker-less setup is best fit for the scenario you describe. If you are just pushing out messages to various nodes from one central process you can use PUB/SUB socket in 0mq (also supports IP multicast via PGM/EPGM). Apart from that, 0mq also provides for various different socket types (PUSH/PULL/XREP/XREQ/ROUTER/DEALER) with which you can create custom devices.

Start with this excellent guide:http://zguide.zeromq.org/page:all

For 0MQ 2.x:

http://github.com/JustinTulloss/zeromq.node

For 0MQ 3.x (A fork of the above module. This supports PUBLISHER side filtering for PUBSUB):

http://github.com/shripadk/zeromq.node

More than 4 years after the question being ask there is an interprocess communication module called node-ipc. It supports unix/windows sockets for communication on the same machine as well as TCP, TLS and UDP, claiming that at least sockets, TCP and UDP are stable.

Here is a small example taken from the documentation from the github repository:

Server for Unix Sockets, Windows Sockets & TCP Sockets

var ipc=require('node-ipc');ipc.config.id   = 'world';ipc.config.retry= 1500;ipc.serve(    function(){        ipc.server.on(            'message',            function(data,socket){                ipc.log('got a message : '.debug, data);                ipc.server.emit(                    socket,                    'message',                    data+' world!'                );            }        );    });ipc.server.start();

Client for Unix Sockets & TCP Sockets

var ipc=require('node-ipc');ipc.config.id   = 'hello';ipc.config.retry= 1500;ipc.connectTo(    'world',    function(){        ipc.of.world.on(            'connect',            function(){                ipc.log('## connected to world ##'.rainbow, ipc.config.delay);                ipc.of.world.emit(                    'message',                    'hello'                )            }        );        ipc.of.world.on(            'disconnect',            function(){                ipc.log('disconnected from world'.notice);            }        );        ipc.of.world.on(            'message',            function(data){                ipc.log('got a message from world : '.debug, data);            }        );    });

Im currently evaluating this module for a replacement local ipc (but could be remote ipc in the future) as a replacement for an old solution via stdin/stdout. Maybe I will expand my answer when I'm done to give some more information how and how good this module works.