I am working with socket.io and node.js. I'm am having problems tracking which users are online because of the few seconds delay before socket IO recognises an XHR-Polling client has disconnected.

If an XHR-Polling client refreshes the page their new connection message seems to precede their disconnection message. This causes confusion when trying to track which users are online.

One solution could be to detect the transport method on the serverside and delay the connection for XHR-Polling clients to ensure that the disconnection functions have been run first.

Has anyone had any experience of this?

I am working with socket.io and node.js. I'm am having problems tracking which users are online because of the few seconds delay before socket IO recognises an XHR-Polling client has disconnected.

If an XHR-Polling client refreshes the page their new connection message seems to precede their disconnection message. This causes confusion when trying to track which users are online.

One solution could be to detect the transport method on the serverside and delay the connection for XHR-Polling clients to ensure that the disconnection functions have been run first.

Has anyone had any experience of this?

• javascript
• node.js
• socket.io
• websocket

• 2 Why can't you just assume a user is online until the disconnect event is fired. I agree you will have an overlap where it will appear two users are online when only one is, but if you identify connections according to certain userid's then there shouldn't be a problem. And if not, worst case scenario is having a user appear online for a few extra seconds. I don't think adding a delay is a particularly solid way to perform good disconnection detection. – davin Commented Jun 8, 2011 at 15:27
• I agree with davin. I use those "this person is online" as best guess estimates that the person is online right then, not as law. If I want to know what they're doing I'll call them. – jcolebrand Commented Jun 8, 2011 at 15:38
• This is something we've added support for in Pusher and we do this using something called Presence Channels. – leggetter Commented Jun 9, 2011 at 11:55

3 Answers 3

The main problem with presence, as @davin and @jcolebrand point out in the ments, is that connections alone can't be relied upon. Network devices can hold on to connections after a user has navigated away from a page. So, you need something else in place to confirm a users presence.

This is something we've added support for in Pusher and we do this using something called Presence Channels.

We manage this using a unique user id, which you (the developer) have to supply when a user connects, in bination with a unique socket id which identifies the connection. Since this unique user id can only occur once within a presence member list it means that that user will only be listed once - even if they have multiple connections open, and thus multiple socket connections.

The same idea can be applied to HTTP connections.

The general approach for this is to use the session to uniquely identify the user. In that way even if they are just a "Guest" you can still identify them as long as they are allowing the use of cookies.

So, the number of users on your system should only ever max at the number of active sessions you have running on your server.

Hope this helps. Let me know if you'd like anything clarified.

I'm developping a chat support solution and the attendent have to know when a client connect. With websocket works fine, but with whr-pooling, sometimes the attendent just disconnect (with 5 seconds in some cases). Sometimes dont heppend. What I do: I just enter the page and wait looking the terminal app.

I'm using nodejs, nowjs

What version of socket.io are you using? I encountered this issue and solved it on this post. It turns out there was a bug introduced in socket.io 0.9.5 on the request sent when the beforeunload event was triggered that prevented the proper disconnection.