On-the-fly game changing without disconnecting players?

[Baker]

[mh]

You'd need a rewrite of the server code in the engine to properly support this. Right now there are a couple of structures that hold server info, with only one instance of each being active at a time. Ideally, all of the sv_*.c files would need to convert to C++ (not difficult, I've personally already done that bit) and the sv and svs structures (at least) would need to convert to classes. You could do it with C, but it would be very messy indeed.

Break out from there into the host code, and Host_Frame and all of it's descendents will also need to be reworked (not too dramatically though) so that they're aware of which server instance they're running against.

Server cvars will need to be instanced too, otherwise someone on Server1 will get a nasty shock when Server2 starts up Ziggurat Vertigo!

You also need a mechanism for tracking which clients are connected to which server instances, as well as arbitrarily moving any client to any server instance, as well as killing off any server instance that drops to 0 clients.

I think the protocol should be OK, so long as the clients can reliably determine which server instance they are connected to. The net code would need some reworking, as a lot of it assumes that there is only one server which all clients listen to. Connections would need to re-route to the correct server, broadcasts would need to know which server they're coming from, stuff like that. You'll probably also want to run each server on a different IP port, so there's something else to do.

Then you're going to start hitting a serious memory overhead - the server keeps copies of all entities in a fixed size array, so take the size of that and multiply by 30. The server also needs it's own copy of the world model (and probably other models too), as well as a lot of other state info. 200 megs is not unreasonable for 30 server instances. OK for LANs, but on the internet your host will start looking at your usage well before you get to there.

Then you need to consider CPU. 30 x the CPU load of a Quake server would make a small load into a fairly large load. To maintain isolation and better use resources, you're looking at moving the server code over to a multithreaded model with a thread pool of some sort supporting it.

Bandwidth - Q1 can utilise 20 Kbps per client as is, so you'll need about 10 megs of bandwidth (adding a little for headroom), and let's hope there's no contention on that line.

There's also 30 x the potential attack surface to consider, so you'll need to ramp up your OS security (and your Quake server security) or one progs.dat which is exploitable could bring the whole thing down.

So yeah, a big job (and I doubt I've even touched on half of it), but one which seems fairly interesting nonetheless.

[mh]

Actually, I think I may have misunderstood the original post.

But the ability to host multiple server instances is something intriguing, don't you think?

[Baker]

[mh]