I am building a massively multiplayer game with Node.js and Socket.io. All players will move around on the same infinite map (think Minecraft). As the player moves I load the tiles that are visible to them. When players move their movement should be sent to all the players that can see them.

My question is; how should I go about structuring my sockets? Having one socket for all players doesn't seem like it would scale. I could shard the world into chunks, but I'm not sure how to manage the chunk boundaries. Since most players won't be able to see each other most of the time I'd prefer that each player's socket only get updates that are relevant to them.

I've read that Socket.io has a concept of "rooms" which are just sockets that get the same messages. Would it be feasible to have a separate room for each connected player to which I would add the socket of any other player who moves nearby? Then each time the player moved I could send a message to that room. How then could I manage when viewers leave or join the room?

Obviously this is a vague question, but I'm just looking for best practice advice. Links to articles on the subject would be appreciated.

This is one of the essential problems in designing MMO servers. Generally you want a socket per client and you implement logic to subscribe a client to a particular region.

Regions are a good way of setting up 'channels' to control data subscription. You could have discrete names for each region and use Socket.io rooms to subscribe players to a region.

After all this is going, things get much easer to handle. So if a player moves in a particular region, all the server has to do is send that 'Player Moved' event to all subscribers of all regions within X meters of the event.