NodeJS + socket.io + PHP to achieve real-time notifications

[JasonLewis]

I'm looking for advice at the moment on achieving real-time notifications using a mix of PHP, NodeJS and socket.io.

At the moment I have done next to nothing with Node and socket.io so I'm at a loss with the best way to achieve this. I've done some basically listening and what not but nothing extreme.

 

For now my questions are:

 

1. How will socket.io know of new notifications, should PHP be responsible for sending the data (say a post was created) to socket.io and from there broadcasting to connected clients?

2. How does socket.io know which clients want the notifications?

 

I'm really not sure what else. This is all a bit much for me at the moment. I just can't get my head around how the notifications will be distributed.

 

Any advice would be greatly appreciated. I don't expect a detailed walk through, just a push in the right direction or some knowledge on how it all meshes.

 

Cheers.

[kicken]

I haven't worked with node or socket.io specifically, but I can give you a bit of the theory rundown on how it would work.

 

1. How will socket.io know of new notifications, should PHP be responsible for sending the data (say a post was created) to socket.io and from there broadcasting to connected clients?

 

Socket.IO will keep in contact with the server using whatever transports are available, starting with websockets and working down to iframe polling.  Most modern browsers will end up using either websockets or XHR long-polling as they are the best techniques available.  Socket.IO likely has a way for you to select a specific transport but I'm not sure on that, documentation will answer that.

 

If you use websockets, then you need a websocket server to communicate with this.  You could do this in PHP or node.js or any other server-side language you desire.  The server will handle sending and receiving information from the client.  The server is where you would have to implement the details of deciding when a new notification needs to be sent and then send it.

 

If you use XHR long-polling then you will have a script on your site somewhere that checks for new notifications and sends them when they are ready.  What will happen is socket.io will make a request to that script using XHR, and will sit their and wait until data is receive.  So your script needs to wait until data is available before sending it, the script would look something like this (pseudo code)

while (!hasNotifications()){
   sleep(5); //pause for a while then check again
}

//At this point we have at least one notification to send,
//so we send it out
sendNotifications();

 

 

2. How does socket.io know which clients want the notifications?

 

This is something you'd have to setup as part of your communication protocol with the client.  For instance you might include the session id in the request and on the server use that to determine who the end user is.  You could generate your own unique token for each user and include that in any communications.

 

 

[JasonLewis]

Thanks for your reply kicken!

 

What I'm getting at is this. Say I post a new update or something, when that update is inserting into the database should I push the notification through to socket.io which then broadcasts that notification to the connected clients? Does that sound feasible? What I want to try to avoid is polling the database every couple of seconds to check for new notifications. I'm using MySQL and I've read that other database's handle that sort of thing a tad better.

 

Edit:

 

This is a quote from another forum:

 

To communicate between php and web sockets I suppose you will need some comet solution. We did it on this way:

1. Have Redis (pub/sub feature) to send/retrieve messages (channel No is user ID)

2. Have PHP to send notifications into Redis when something happen

3. Have Node.js app listen all channels and send notification to web sockets

 

How to identify user:

1. After user login we added to Redis hash pair: sessionID => userID

1. After user connected to socket, it send auth command to node.js with session ID.

2. Node.js check hash in Redis for sessionID and get userID.

3. Node.js subscribe connection to userID channel

 

I can make sense of that... I'll just need to implement Redis since I don't have it at the moment.

[JasonLewis]

Just an update for people. I'm approaching this like I've posted above. I'll be making use of Node/Socket.io/Redis (pub/sub feature) to handle real-time updates for notifications and other related components.

 

Once I get it working properly I'll post how I did it all for future reference.

[Monkuar]

I haven't worked with node or socket.io specifically, but I can give you a bit of the theory rundown on how it would work.

 

 

 

Socket.IO will keep in contact with the server using whatever transports are available, starting with websockets and working down to iframe polling.  Most modern browsers will end up using either websockets or XHR long-polling as they are the best techniques available.  Socket.IO likely has a way for you to select a specific transport but I'm not sure on that, documentation will answer that.

 

If you use websockets, then you need a websocket server to communicate with this.  You could do this in PHP or node.js or any other server-side language you desire.  The server will handle sending and receiving information from the client.  The server is where you would have to implement the details of deciding when a new notification needs to be sent and then send it.

 

 

Which module let's us use our socket.io server written in PHP?

 

Cause I am using socket.io right now, and I hate javascript. Much rather use PHP's language style.

Edited November 26, 2014 by Monkuar

[boompa]

Could try this: http://socketo.me/