[crossfire] C++/Qt server version

[Anton Oussik]

2008/11/25 Alex Schultz <agschult at ucalgary.ca>:
> On Mon, 24 Nov 2008 22:06:40 -0800
> Mark Wedel <mwedel at sonic.net> wrote:
>
>> Shared strings:  While perhaps no reason to get rid of them, I also
>> wonder how necessary they are now days.  They do simplify
>> comparisons.  And with C++ and proper class descriptions, they can be
>> made to be safe (have to use class functions to modify the name,
>> and it knows to do the right thing).  But shared strings date back a
>> long time in crossfire, to when systems had much less memory and this
>> wasmore a concern.  They certainly do still save space, but the amount
>> of space saved may not be worth the extra handling.  It should
>> certainly be reviewed - many design decisions date back to when
>> computers where much less capable than they are now, and may not make
>> much sense.
>
> I'm note sure exactly how much space is saved, but I think there's a
> high chance they may still be desirable due to the shear amount of
> floor tile objects and such in CF if someone is running through a large
> number of large maps. Now it's possible the benefit might be small
> these days but in any case, I don't think that making decisions about
> shared strings can go much further without getting real data on how
> much space they save.
>
> <snip>
>
>> Distributed server archetype: Need more details - having redundancy
>> (client rerouting with minimal data loss) might not be worth the
>> effort - have to make sure you don't have two servers trying to
>> control the same area, recovery when one comes back on-line, etc.
>> But being distributed (this server is responsible for scorn region,
>> this one for navar city, etc) to reduce load may make sense, with
>> there being smarts to transfer character detail between those, etc.
>> In terms of server failure/crash, the client could improve that
>> experience - most servers restart when they crash, so it is really to
>> the client to pop up a window with something like 'connection lost -
>> trying to reconnect (with spinning disk or something)'.
>>
>> Multithread server:  I think this is a must - computers are moving
>> more and more towards multiple cores, and less towards raw speed, and
>> for crossfire to make use of those really requires multithreading.  I
>> always thought that multithreading at the map level would make the
>> most sense - this potentially lets one use many threads (and thus
>> cores) and is probably the simplest way to go.
>
> I was recently thinking about server multithreading, and now I'm
> thinking, why bother with threads? Why not do a model like
> one-process-per-every-few-maps instead of multithreading? It eliminates
> potential issues with mutexes and locking and such, transfering things
> between the processes could be done by IPC. The further advantage of
> going with a multi-process model instead of multi-thread model, is that
> much of the very same code could be adapted to make a distributed
> server possible if anyone ever thinks there's a need. I don't
> currently think there's a need for a distributed server system, but a
> multi-process model would lend well to adapting to distributed at a
> later date. Furthermore, a multi-process model would also make server
> crashes less disruptive because they'd usually just kill off a map or 3
> instead of everywhere. Perhaps we should make a pros/cons chart to
> outline the merits of multi-process and multi-thread to compare?

I think an multiprocess architecture that is capable of being run on
multiple machines is a good direction to move in.

I propose to have one process that handles connections from clients,
keeps them connected, keeps track of who is on which map, and is
capable of kicking off map processes as needed.
Then, have one process per map, which can potentially run on a remote machine.

As some tasks (like logging in) put a lot of strain on the main
process (which would have a lot going through it anyways), perhaps
some other things could be migrated off it into their own processes,
instead going for a pure message passing process, which maintains the
mapping of which player is connected to what map, and passes messages
in both directions.

Maps talking to maps could be done simply by a map asking where
another map is running, and then connecting directly to transfer data
between maps. This would allow spells to work across maps without
overloading the central process etc.

This has the advantages of splitting the load of running maps over
multiple machines/cores. Only one process would need to listen on a
port, so firewalling a server from outside would be easy.

Another advantage would be allowing maps to crash without bringing
down any other maps. One recovery method would be to place players in
a limbo map, giving them the option to return to the restarted version
of the map, or go home to their savebed. If the recovery map crashes
too we know there is something wrong with the player, and they should
not be allowed on any new maps until something is done about it.

The central process can be kept small and clean, making it fast and
stable, meaning "the server" as the players see it won't ever go down,
even when upgrading, since upgrades can then be applied to a running
server without the need to restart it. Most changes would be to the
map running processes, which will be automatically applied when maps
are restarted.

The disadvantages of this are: extra level of IPC is potentially slow.
The configuration can get complex unless thought out well in advance.