robbles
robbles

Reputation: 2809

Socket.io receives messages before browser navigates to new page

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:

  1. Socket.io connects
  2. User triggers a page navigation (submits a form, refreshes, etc.)
  3. Server-side logic sends a request to the socket.io server, which immediately dispatches the event to the still-connected client
  4. The client receives and confirms the request (I'm pretty sure there's some confirmation of messages built-in to socket.io, correct me if I'm wrong), and would display a notification to the user, but then ...
  5. The socket.io connection closes on the original page
  6. The new page loads and displays
  7. Socket.io opens a new connection, but there's no new messages, because the last one was received and confirmed.

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

Answers (2)

robbles
robbles

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

josh3736
josh3736

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. User is on a page connected to sio session 1.
  2. We begin navigation to new page. On 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.
  3. A new page is loaded. It will connect to the Socket.io server and be assigned a new session ID, 2.
  4. Anything you send to session 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:

  • Since you're doing a full page load, you can send queued notifications directly down with the page itself. Delete the queue when you've successfully rendered.
  • On a new Socket.io connection, send unread notifications over the socket. Give .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

Related Questions