CODEWITHSUNDEEP
javascriptnode.jssocketssocket.ioserver
Danny
Danny

Reputation: 599

Socket.io and Node.Js multiple servers

I'm new to Web Sockets in general, but get the main concept.

I am trying to build a simple multiplayer game and would like to have a server selection where I can run sockets on multiple IPs and it will connect the client through that, to mitigate connections in order to improve performance, this is hypothetical in the case of there being thousands of players at once, but would like some insight into how this would work and if there are any resources I can use to integrate this before hand, in order to prevent extra work at a later date. Is this at all possible, as I understand it Node.Js runs on a server and uses the Socket.io dependencies to create sockets within that, so I can't think of a possible solution to route it through another server unless I had multiple sites running it separately.

Upvotes: 1

Views: 1672

Answers (1)

Noel Baron
Noel Baron

Reputation: 736

The first question I have is this:

Are you hosting on AWS or in a local datacenter?

The reason I ask is because SOCKET.io requires sticky sessions to work properly across multiple servers. Due to the fact that SOCKET.io will attempt to upgrade each connection, and because that upgrade request must reach the original server that authorized the session, you'll need to route websocket (TCP) connections back to that original server via sticky sessions. Unfortunately AWS makes this extremely tricky and will require you to learn how to:

A) Modify elastic load balancer policies to forward protocol information B) Split apart TCP connections from standard web requests using something like HA PROXY or NGINX. This is necessary in order to handle web socket UPGRADE requests properly, as you will be setting TCP to sticky and web requests to round-robin. C) Attach your socket.io configuration to a common storage source, like Redis (elasticache).

Once you've figured out what's needed for AWS (or if you've got full control over request routing at your local datacenter), you'll want to architect your SOCKET application to use multicast rooms rather than direct socket messaging.

Example: To send a message to users in game #4444, emit a message to room 'games:4444', rather than direct to the user's socket.

If your socket instance is configured using REDIS, REDIS will automatically take care of maintaining lists of people who are connected to your 'games:4444' channel. Otherwise you'll need to maintain the list yourself using a database or other shared mechanism.

Other than that, there are plenty of resources online that can help you figure out each step along the way. I'd start with understanding something like HA PROXY and how it can help split apart your SOCKETS from your web requests.

Upvotes: 2

Related Questions