[crossfire] C++/Qt server version

[Alex Schultz]

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?

Alex Schultz