0

I am trying to build a realtime multiplayer game with Node / SocketIO on Heroku and am not sure how to handle multiple dynos with regards to sharing SocketIO connection data.

For example:

  1. I have 2 Heroku dynos, each running Node + SocketIO
  2. Player A hosts a game, and dyno 1 handles that connection
  3. Player B attempts to joins the same game, but due to the Heroku router, dyno 2 ends up handling that connection.
  4. Actions in the game need to happen in real time, so when Player A performs an action Player B needs to immediately see the results of that action.

In a single-dyno environment, this would be relatively simple. When Player A performs an action, it simply gets emitted to player B. How would this work when there are multiple dynos?

Albert Peng
  • 1
  • 1

1 Answers1

2

Since you aren't able to select (or know) which Heroku dyno you're connecting to (web.1, web.2, or web.n), you will need to find another way to communicate changes in the game across many dynos.

One way to do this would be to additionally use a distributed messaging service for communicating changes in the game. Using a distributed publush-subscribe architecture Player A can send actions in the game to dyno 1, which then puts them on a queue.

Dyno 2 can then subscribe to the game's queue when Player B joins the game. Now, Dyno 2 will receive actions from the game and then be able to send them over the socket to Player B.

While this approach isn't going to be as low of latency as a single high-performance server, something like it might be necessary if you want to get the benefits of scaling and redundancy.

On Heroku, you might consider using Redis for this purpose, since Heroku provides a hosted version and it performs well for low-latency applications.

harperj
  • 63
  • 5