Reputation: 2809
I'm having an issue with Socket.io receiving messages just before a page navigation happens - generally when the message is a direct result of some server-side action triggered by the navigation.
What I'm seeing right now looks like this:
This isn't really a bug, per se, since I don't think it's reasonable to expect Socket.io to close the connection in advance of a navigation occurring. However, I'm not really sure what the best way to handle this is. Currently I keep one connection open per-client at a time, and close the other when a new one connects. This doesn't happen in this case though, since the first one has closed before the second one connects. I also could keep a list of all clients, but that wouldn't solve this problem either, because the message would still be received by the first connection.
Can someone suggest a solution to this problem that would ensure the user always sees a notification for the message?
Upvotes: 4
Views: 2527
Reputation: 2809
Simplest solution: Use the onbeforeunload event to disconnect socket.io.
I verified with a HTTP debugger that this event fires before the browser issues the request (at least in Chrome) so if socket.io is disconnected here, it won't receive any messages meant for the following page.
window.onbeforeunload = function() {
socket.disconnect();
};
I haven't tested this in multiple browsers, so it might not be a perfect solution, but it seems to solve the problem for now.
Upvotes: -1
Reputation: 144882
Socket.io tracks logical connections with its own session IDs. If you watch the console when a client connects, you'll see the IDs:
info - handshake authorized Q9syoIK47JI7dACYpxiA
What's important to understand is that those IDs are per-page, and completely separate from HTTP sessions. The Socket.io client library simply holds its session ID in a JavaScript variable. Therefore, upon navigation, the ID is obviously lost.
So, upon navigation, this happens:
1
.window.onbeforeunload
, Socket.io initiates a synchronous XHR request to tell the server it is disconnecting. If it succeeds, the session (1
) is immediately terminated; otherwise, the session will eventually time out.2
.1
will obviously not be delivered since our client is now connected to session 2
.With the base Socket.io functionality, it is impossible to distinguish between a user who navigates between pages and a new user. In either case, the user will connect to a new Socket.io session.
Without knowing exactly how your app works or what you're trying to accomplish, it's hard to give a definitive recommendation for solving your problem.
Most likely, what you need to be able to do is associate a Socket.io session with the user's HTTP session. You can store notifications in a queue in the user's session, and delete them when they are displayed. There are two ways of doing this:
.emit
a callback function – this is the confirmation of delivery that Socket.io provides you. When delivery is confirmed, you can delete the notification queue from the user's HTTP session.Upvotes: 4