In need of multiplayer server advice
by Frank Korf · in Torque Game Engine · 08/27/2007 (11:51 am) · 4 replies
I want to create a single server (box) that can host multiple multi-player games, (the more games the better) and I am in need of some advice. I'm not experienced with server programming/optimization, so bear with me.
As I see it there are two options:
1) Create a new instance of a Torque dedicated server for each multi-player game, each on a different port.
The pros of this approach seem to be that it would require no modifications to the engine, and if one server instance failed, it would not (necessarily) crash the others.
2) Create several multi-player games within one instance of a Torque dedicated server. Again, each game instance would map to a different port.
The pros of this approach seem to be that it would be easier on system resources. If two games share the same map or models, I think the engine would load a single instance for each them, instead of duplicating them for each game. Right? The engine modifications required, however, are more than a bit intimidating. I don't know if the stock engine can handle multiple game instances in one dedicated server, so there's that part. Also, this approach appears to require a change in the way the engine handles IDs, because if the server were running for a while the engine would run out. In fact, all of the garbage collection involved appears scary.
Both methods would require some sort of manager program, which would be in charge of creating new games when necessary, but I'm not really worried about that... yet.
Any thoughts?
As I see it there are two options:
1) Create a new instance of a Torque dedicated server for each multi-player game, each on a different port.
The pros of this approach seem to be that it would require no modifications to the engine, and if one server instance failed, it would not (necessarily) crash the others.
2) Create several multi-player games within one instance of a Torque dedicated server. Again, each game instance would map to a different port.
The pros of this approach seem to be that it would be easier on system resources. If two games share the same map or models, I think the engine would load a single instance for each them, instead of duplicating them for each game. Right? The engine modifications required, however, are more than a bit intimidating. I don't know if the stock engine can handle multiple game instances in one dedicated server, so there's that part. Also, this approach appears to require a change in the way the engine handles IDs, because if the server were running for a while the engine would run out. In fact, all of the garbage collection involved appears scary.
Both methods would require some sort of manager program, which would be in charge of creating new games when necessary, but I'm not really worried about that... yet.
Any thoughts?
#2
In theory option 1 is fairly simple, my personal approach would be to develop my own Master server (there are resources already for doing this, also there is one in the torque network library which is open source should you be developing your game under the right license) this master server could create the seperate instances of the servers.
08/28/2007 (7:55 am)
Frank - your option 1 would be a lot simpler to implement, a dedicated torque server isn't capable out of the box to run multiple instances of a mission for differing groups of players it would require a lot of the server side to be rewritten.In theory option 1 is fairly simple, my personal approach would be to develop my own Master server (there are resources already for doing this, also there is one in the torque network library which is open source should you be developing your game under the right license) this master server could create the seperate instances of the servers.
#3
08/28/2007 (10:18 am)
Thanks for the suggestions. I think I'll start by going the master server route.
#4
It's not too hard to add signal handling code to allow a Torque server to fork(). I've done it. In stock Torque, there's very little you need to reinitialize to make it work (mainly, you need to rebind to a different listen port in the fork'ed instance, and reinit a few variables to make them unique/distinct). With Linux' copy-on-write behavior, this will save you a ton of heap (because all the geometry and a bunch of other static stuff never gets written to).
In our environment, a moderately complicated mission takes ~60MB of heap after it's loaded up (and the unneeded resources are purged). A fork'ed copy of that process takes an additional 8-10MB of heap, whereas, running a seperate process will take another 60MB.
This option (or option 1) are both pretty straightforward... I wouldn't suggest doing option 2.
08/28/2007 (10:22 am)
Quote:
Frank - your option 1 would be a lot simpler to implement, a dedicated torque server isn't capable out of the box to run multiple instances of a mission for differing groups of players it would require a lot of the server side to be rewritten.
It's not too hard to add signal handling code to allow a Torque server to fork(). I've done it. In stock Torque, there's very little you need to reinitialize to make it work (mainly, you need to rebind to a different listen port in the fork'ed instance, and reinit a few variables to make them unique/distinct). With Linux' copy-on-write behavior, this will save you a ton of heap (because all the geometry and a bunch of other static stuff never gets written to).
In our environment, a moderately complicated mission takes ~60MB of heap after it's loaded up (and the unneeded resources are purged). A fork'ed copy of that process takes an additional 8-10MB of heap, whereas, running a seperate process will take another 60MB.
This option (or option 1) are both pretty straightforward... I wouldn't suggest doing option 2.
Tim McClarren
Default Studio Name
If you are deploying on Linux, you can make a forking server (option 3).