CODEWITHSUNDEEP
google-app-enginewebsocketgoogle-compute-engine
benkraus
benkraus

Reputation: 707

Scaling WebSockets on Google Compute Engine

I would like to implement a chat system as part of a game I am developing on App Engine. To implement this, I would like to use WebSockets, and have clients connect to each other though a hub, in this case an instance of GCE. Assuming this game needed to scale to multiple instances on GCE, how would this work? If I had a client 1, and the load balancer directed that request of client 1 to instance A, and another client (2) came in and was directed to instance B, but those clients wanted to chat with each other, they would each be connected to different hubs, and would be unable to reach each other. How would this be set up to work with scale? Would I implement it using queues, where each instance listens on that queue, and if so, how would I do that?

Upvotes: 3

Views: 2468

Answers (2)

FDIM
FDIM

Reputation: 1989

I didn't try to implement this yet but I'll probably have to soon, I think it should be fairly simple to handle it yourself.

You have: server 1 with list of clients and you have server 2 with another list of clients, so if client wants to send data to another client which might be on server 2, you have to:

  1. Lookup if the receiver is on current server - if it is, you just send it (standard)
  2. Otherwise you send the same data to all other servers you have, so they would check their lists for particular client (or clients) and send data to them.

Upvotes: 0

kyokpae
kyokpae

Reputation: 121

Google Play Game Services offers exactly the functionality that you want but in regard to Android and ios clients. So this option may not be compatible with your game tech design.

In general you're reasoning correctly. Messages from client who want to talk to each other will most of the time hit different server instances. What you want to do is to make instances handle the communication between users. Pub/sub (publish-subscribe pattern) is very suitable pattern in this scenario. Roughly:

  • whenever there's a message directed to client X a message is published on the channel X,
  • whenever client X creates a session, instance handling it subscribes to channel X.

You can use one of many existing solutions for starters. It's very easy to set this up using redis. If you need something more low-level and more flexible check out zeromq.

You can expect single instance of either solution to be able to handle thousands of QPS.

Unfortunately I don't have any experience with scaling neither of these solutions so can't offer you any practical advice as to the limits of their scalability.

PS. There are also other topics you may want to explore such as: message persistence and failure recovery I didn't address here at all.

Upvotes: 2

Related Questions