I have a client/server application using nodejs on the server and socket.io as the connection mechanism. For reasons relevant to my application I want to have only one active connection per browser, and reject all the connections from other tabs that may be opened later on during the session. This works great with WebSockets, but if WebSockets is not supported by the browser and XHR-polling is used instead, the disconnection never happens, so if the user just refreshes the page, this is not interpreted as a reconnection ( I have a delay for reconnection and session restoring), but as a new tab, which ends in the connection being rejected because the old connection made by this same tab is still active.
I'm looking for a way to effectively end the connection from the client whenever a refresh occurs. I've tried binding to the beforeunload and calling socket.disconnect() on the client side, and also sending a message like socket.emit('force-disconnect') and triggering the disconnect from the server with no success. Am I missing something here? Appreciate your help!
I've read this question and couldn't find it useful for my particular case.
Solved the issue, it turns out it was a bug introduced in socket.io 0.9.5. If you have this issue just update BOTH your server and client-side code to socket.io > 0.9.9 and set the socket.io client-side options sync disconnect on unload to true and you're all set.
Options are set this way:
var socket = io.connect('http://yourdomain.com', {'sync disconnect on unload' : true});
You can also get "Error: xhr poll error" if you run out of open file descriptors available. This is likely to happen during a load test.
Check the current open file descriptor size:
ulimit -n
Increase it to a high number:
ulimit -n 1000000
Related
I am working on a socket io app using nodejs and redis cache.
I recently upgraded my socket and socket client to the latest version4. My socket app was running on version2. During a disconnect the socket('disconnect') on manager used to get the error reason pinged timeout in version 2, where as the reason for the same error is changed to transport close in version 4. I have the same ping timeout which is set to the max of 60000. Can anyone help on what I am missing here.
The reason I am concerned on the error reason transport close is because, window or tab close shows the same reason. The app currently close for that reason logging out the user. This was used on top of the beforeUnload close to ensure that the user is removed from the redis cache on disconnect.
can anyone suggest a way to differentiate between the reason of transport close between disconnect and window close.
I'm using node.js, websockets/ws.
In my site sometimes a random client loses connection without losing connection to other internet stuff. Less then a second later they connect back, with a new socket. (There is a code that calls socket.onClose, which tries to reconnect back to server)
On the server side I can't see or log anything wrong. Everything looks like a normal disconnect, same as closing the browser tab.
I am guessing the reason is either socket related or client related but I don't know where to begin to debug this problem.
I got ping/pong responses with 60 second timer, this isn't it. The user usually loses connection while active.
How can I debug this problem and find the reason?
I keep all the session info, data, within the socket and that is why I do not want people to lose their connection.
Thanks
I have a production app that uses socket.io (node.js back-end)to distribute messages to all the logged in clients. Many of my users are experiencing disconnections from the socket.io server. The normal use case for a client is to keep the web app open the entire working day. Most of the time on the app in a work day time is spent idle, but the app is still open - until the socket.io connection is lost and then the app kicks them out.
Is there any way I can make the connection more reliable so my users are not constantly losing their connection to the socket.io server?
It appears that all we can do here is give you some debugging advice so that you might learn more about what is causing the problem. So, here's a list of things to look into.
Make sure that socket.io is configured for automatic reconnect. In the latest versions of socket.io, auto-reconnect defaults to on, but you may need to verify that no piece of code is turning it off.
Make sure the client is not going to sleep such that all network connections will become inactive get disconnected.
In a working client (before it has disconnected), use the Chrome debugger, Network tab, webSockets sub-tab to verify that you can see regular ping messages going between client and server. You will have to open the debug window, get to the network tab and then refresh your web page with that debug window open to start to see the network activity. You should see a funky looking URL that has ?EIO=3&transport=websocket&sid=xxxxxxxxxxxx in it. Click on that. Then click on the "Frames" sub-tag. At that point, you can watch individual websocket packets being sent. You should see tiny packets with length 1 every once in a while (these are the ping and pong keep-alive packets). There's a sample screen shot below that shows what you're looking for. If you aren't seeing these keep-alive packets, then you need to resolve why they aren't there (likely some socket.io configuration or version issue).
Since you mentioned that you can reproduce the situation, one thing you want to know is how is the socket getting closed (client-end initiated or server-end initiated). One way to gather info on this is to install a network analyzer on your client so you can literally watch every packet that goes over the network to/from your client. There are many different analyzers and many are free. I personally have used Fiddler, but I regularly hear people talking about WireShark. What you want to see is exactly what happens on the network when the client loses its connection. Does the client decide to send a close socket packet? Does the client receive a close socket packet from someone? What happens on the network at the time the connection is lost.
webSocket network view in Chrome Debugger
The most likely cause is one end closing a WebSocket due to inactivity. This is commonly done by load balancers, but there may be other culprits. The fix for this is to simply send a message every so often (I use 30 seconds, but depending on the issue you may be able to go higher) to every client. This will prevent it from appearing to be inactive and thus getting closed.
I'm using Node.JS and Socket.IO to create a chat, I use XHR polling with a duration of 10 to host it on Heroku.
When I leave the page with my client, I'd like to calll the disconnect method automatically on the server which removes it from other clients. It's in fact done but... 2 minutes after the client has really left the page, which is quite awkward.
Is there a way to call the disconnect method as soon as the client doesn't reply ? Or at least being a little faster to know when the client is not there anymore ?
I've tried to close the socket client-side on page exit with jQuery but it doesn't work. The problem is that using socket.disconnect() is asynchronous and non-blocking and the user leaves before the request is completed...
You can play with heartbeat timeout, heartbeat interval and close timeout values of socket.io configuration.
Search for heartbeat and timeout in this page: https://github.com/LearnBoost/Socket.IO/wiki/Configuring-Socket.IO
If you set the 'sync disconnect on unload' option on the socket.io client to true, it will send a synchronous xhr disconnect request in onbeforeunload that will disconnect the socket.
I have a page on which users connect to my node server with socket.io but I only allow them to have one open socket.io connection to the server (by passing along their account id when authorizing them and storing it in an array) and this works fine 99% of the time. The problem is that sometimes when users disconnect, the serverside disconnect event doesn't fire for some reason, so I can't clear their account from the array of clients, which ends up with them being locked out.
Is there a way for me to check if their old socket connection (which I have the ID of) is still active? (So if it isn't I can clear their old connection and let them connect again)
Make sure that heartbeats is set to true (the default). If the timeout lapses, disconnect should happen automatically. However, there was a bug report about heartbeats not working. Make sure you have the latest version of Socket.IO (I'm not sure the status of the bug).
If you still need help, you could send a ping to the old connection when the user tries to reconnect:
Emit a 'ping' from the server, and reply with 'pong' from the client if the connection is still alive. If the ping times out (after say, 20 seconds), drop the connection manually so the user can reconnect. You could use the ping to notify the original client that another client is trying to connect, and raise some UI to that effect.