How to decouple a realtime game architecture

Question

I have a realtime HTML5 canvas game that runs off a node backend. Players are connected via Websocket (socket.io). The problem is sometimes I need to deploy new code (hotfixes for instance) and restart the server but I don't want to disconnect players.

My idea for this was to divide the websocket server and application server into separately deployable components and add a message queue in the middle to decouple the 2 components. That way if the application server was rebooting there would just be a short delay while the messages bunch up but nothing would be lost. Is this a good strategy? Is there an alternative?

Answer 1

It's very possible for websocket based applications to be restarted without the user noticing anything (that's the case for my chat server for example).

To make that possible, the solution isn't to have a websocket application isolated and never restarted. In fact this would be very optimistic (are you sure you could ensure its API is never changed ?).

A solution is

1. to ensure the client reconnects if disconnected (this is standard if you use socket.io for websocketing)
2. to make the server ask the client its id (or session id) on client initiated reconnection
3. to persists the state of the application. This is usually done with a database. If your server has no other state than the queue between clients (which is a little unlikely) then you might look for an existing persistent queue implementation or build your own over a fast local storage (redis comes to mind)