Jump to content
  • Advertisement
Saikodan

Multiplayer network: Using RabbitMQ

Recommended Posts

Hi, need some help :)

Started working on a multiplayer server for my game. At the start, I've used some socket library, defined every type of message and handled the connections and everything myself. And then I thought of something - why not use RabbitMQ?

Instead of creating socket connection to each client, I can just define queue for each client. Rabbit can handle a huge load, and I can use it to establish connections between my server and clients easily - I just need another server to handle incoming connections from each user and tell them where to subscribe (which queue). All of my clients publish in one channel for the server, but my server publishes for each client on a specific queue.

 

Am I missing something here? Will rabbit give me fare performance? I'm not expecting it to be the best solution, but it sounds much easier then defining everything by myself.

 

Share this post


Link to post
Share on other sites
Advertisement

It all depends on the type of game, the update frequency, and the amount of data you are sending.  Are you doing authoritative physics for a real-time shared simulation like in a fast FPS game?  Then this "might" not work for you.  It all depends on how much performance you need, and how much data you are intending to send/receive.  There's also TCP vs UDP, RabbitMQ I believe only works over TCP, so you'll be incurring significant extra lag when you lose packets.

If your game only needs to communicate simple data bits infrequently (10 updates per second or less), and you can tolerate up to 1second lag times, then you might be fine.  ;)

Otherwise I would recommend a library that uses UDP or writing the UDP netcode code yourself.

Best of luck!

Edited by Septopus

Share this post


Link to post
Share on other sites

There are two things you need to consider here.

First: Message queues are great at throughput -- measured in megabytes per second or perhaps messages per second. But they generally get this benefit by being less great at latency. There may be significant initial latency even at low load, and latencies may start going up as load increases. If you measure these quantities, and they are sufficient for your gameplay needs, then that's not an actual problem for you, but for most action-oriented games, these have not worked out in the past.

Second: Message queues are generally programmable APIs. But you don't want your players to program the message queue, so you have to make sure that the security configuration of the message queues is water tight. Often this ends up being hard because the notion message queues have for queue lifetime, or permissions, or users, match poorly with the needs of a multiplayer game. (One message queue I tested ten years ago had to be restarted each time a new user was added to the set of allowed users!) The work-around here is generally to build a front tier of application servers that actually talk to the game clients, and not let the game clients talk directly to the message queue. The application servers then have to do user identification and topic permission checking in a way that matches the need of the game. At that point, the message queue is just a back-end switching fabric, and there are plenty of other options that might work just as well, or better, for games -- from "there's one server, and everything talks in memory" to "everyone shares a UDP broadcast domain" to "Use ZeroMQ for application servers to find each other and route messages" to "use Redis Pub/Sub" are all reasonable options, depending on the specifics of your game.

Which of these properties matter for your particular game? I don't know. You'll have to figure it out and let us know!

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!