CODEWITHSUNDEEP
dockerwebsocketkubernetescontainersreal-time
online
online

Reputation: 5507

How to use Kubernetes to do multiplayer online game with websocket?

If develop a online real time game with websocket, multiplayers running on the different containers, how to sync data when add or reduce containers if they are playing?

Does kubernetes has any good feature on this case?

Upvotes: 1

Views: 599

Answers (2)

Matruskan
Matruskan

Reputation: 353

ThatBrianDude already gave an awesome answer, and mine will not be that good. But I think your last comment gave us more hints about the architecture you have in mind. I hope my humble answer will shed a light on more ideas to your game. Here are some suggestions:

First, avoid keeping any state in the websocket apps.

The basic idea with containers is that they should be stateless. ThatBrianDude

So, why not use caches and a messaging layer to help you with that. Imagine the following examples:

Situation 1: if the client sends an action to the websocket server, the server should put it in a queue/topic (some other service will process it later on).

Situation 2: The server might also listen to a(some) topic(s) for some types of messages, and send them back to the clients that need that information.

Situation 3: when the client asks for information or if the websocket server needs some information to send to the client, the server must read it from a cache, as reading from DB might be slow for a multiplayer game.

Situation 4: eventually a container is killed. The clients connected to that server will receive a connection error, and should reconnect. That means another handshake, and the player might feel it, depending on what the game was doing, so killing a container should not happen that often. But that would be just it, no information is lost.

This way, the websocket server containers are totally stateless, and the messaging topics and caches will help you to: provide all the information needed to containers, and; keep websockets, persistance and processing isolated and scalable.

Summing up, the information would flow like this:

  1. clients are showering the websocket server containers with actions
  2. websocket servers just send them to the messaging layer
  3. processing containers (which can be scalled too!) receive those messages, process them, save to the database and/or to a cache and eventually send more messages to other topics
  4. (optional) websocket servers receive those messages and send them to the clients.

Or like this:

  1. clients ask for information or websocket servers periodically need to send the world state to clients
  2. websocket servers look up the information in the cache
  3. and send it to the clients.

Or even like this:

  1. Some processing servers are independent of messages, they just read the game/world state (from the cache?) periodically
  2. they process the physics and mechanics of the game
  3. and save the result back in the cache, which will be sent to the clients by the websocket servers periodically, or send it in a topic so the websocket server can listen to it and send it to the clients.

Lastly, don't forget the suggestion to have one machine responsible for one game/world. It would be nice if each processing server (or each thread of a server) works with one game/world. That would make it easier to persist things without the need to sync stuff.

Upvotes: 3

ThatBrianDude
ThatBrianDude

Reputation: 3190

The basic idea with containers is that they should be stateless.

This means that any persistant data your game might have (highscores etc.) must be saved to a persistant DB whereas other temporary data like current ingame score or nickname etc. can stay inside the memory of the container and be gone once the container dies.

how to sync data when add or reduce containers if they are playing?

This sounds like you want to use multiple containers computing one game world?

Thats a whole other beast on its own but you might want to take a look at SpatialOS which pretty much allows for massive multiplayer worlds and is designed for games that require more than one machine per world.

If thats not what you are looking for I would recommend you to keep one machine responsible for one game/world as you will avoid high complexity when you try to sync stuff later on.

Upvotes: 0

Related Questions