I saw this snippet:
io.sockets.on('connection', function(socket) {
const subscribe = redis.createClient();
const publish = redis.createClient();
socket.on('publish', function(channel, data) {
publish.publish(channel, data);
});
socket.on('psubscribe', function(channel) {
subscribe.psubscribe(channel);
});
subscribe.on("pmessage", function(pattern, channel, message) {
socket.emit('message', { channel: channel, data: message });
});
});
$(".action").click(function() {
socket.emit('publish', 'game.#{gameid}.action.' + $(this).data('action'),
JSON.stringify({ nick: "#{nick}", ts: Date.now() })
);
And I'm wondering why? Doesn't Socket.IO have its own broadcast mechanism? Why choose Redis' Pub-Sub over Socket.IO? Can't we just do like this:
io.sockets.on('connection', function(socket) {
socket.on('action', function(channel, data) {
socket.broadcast.to(channel).emit(data)
});
});
And if there is a reason to use Redis, what would be the benefit? Persistence?
Aside from data storage, Redis can be used as a Publisher/Subscriber platform. In this pattern, publishers can issue messages to any number of subscribers on a channel. These messages are fire-and-forget, in that if a message is published and no subscribers exists, the message evaporates and cannot be recovered.
The first is that a message queue is pull-based, while pub/sub is push-based. This means that when using a message queue a subscriber (or consumer) needs to poll the queue for messages, while in a pub/sub the subscriber gets push notifications, meaning there is no polling needed.
Broadcasting also works with multiple Socket.IO servers. You just need to replace the default Adapter by the Redis Adapter. More information about it here.
Now, if you use socket.io with the Redis store, socket.io will use Redis pub/sub under the hood to propagate messages between servers, and servers will propagate messages to clients.
The reason I chose to use Redis Pub Sub with Socket.io in my Real Time Activity Stream project (http://blog.cloudfoundry.com/2012/06/05/node-activity-streams-app-2/) was because I wanted to have multiple web servers (instances on Cloud Foundry or dynos on Heroku). As far as I could see, Socket.io stores the messages in memory (of one webserver), so how it could possibly broadcast to clients which are connected to another webserver?
Check out the post and let me know if it helps
Redis is used here for at least two reasons. The first one is that it works really well as a publish and subscribe mechanism, including being able to select messages based on pattern matching to psubscribe. The second reason is the ease of other clients to be able to publish and subscribe through the redis mechanism. That is not to say that it is impossible, just convenient. This combined with the asynchronisity of node.js makes a powerful partnership.
It's not the only solution of course but one that seems to work rather well.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With