[crossfire] Re: Moving server towards a modularized system?

[Anton Oussik]

On 18/01/06, Yann Chachkoff <yann.chachkoff at myrealbox.com> wrote:
> > I for one frown on the idea of making the server slower
>
> There is no reason that it would be slower than it is now. There are no
> reason for a modularized system to be slower than the current version. The
> only overhead would be when connecting callbacks to objects - and that's
> hardly something you'd notice, unless if you're running Crossfire on a
> 8086 at 8Mhz...

Actually, this will depend on how modular the code will be. Going back
to Hurd analogy for a second, one of the reasons has not become widely
used yet is not because it is modular, but because being so modular
makes IPC (Inter-Process Communication) slow (using the GNUMach
microkernel), as processes are forced to make frequent calls to the
kernel, and therefore the whole thing runs about 66% slower [than
Linux].

There is a theoretical design with will make it only 15% slower or so
(Hurd on L4), but it seems to have other problems, so the project is
no longer sure what kernel it will run on when the Hurd gets released.
Effectively, most of the development is spent looking for an
architecture that is both modular and fast, and therefore it may look
like real "development" is not happening.

The same thing can be done to Crossfire, making one "core" module,
which will be tasked with starting up, parsing command line arguments,
and starting up all other things as modules, provide a way of
synchronising them and provide Inter-Module communication. If a
message is sent to a module that is not currently there the core would
then try to load that module before failing, so the random map
generator only gets loaded after someone decides to enter a random
map. This feature will also make handling errors easier, so if a
person enters a random map, and random map generator is not avaliable,
it will be possible to display an error to the player, like "The total
chaos inside prevents you from entering".

The player could then decide to build and install just the random map
generator, and the server would not need to be restarted to apply the
changes. Likewise for all other components, so applying a security
update will not mean restarting the server.

Also if some module segfaults, it will not need a restart of the whole
server, but simply of that module. This should aid the server
stability, as "something wrong when casting meteor swarm resulting in
the spell not working" will not disturb someone else killing dragons
in a dungeon.

Having the code highly modular also will mean each module can be
started as a seperate process (or thread, but that is slightly less
portable, if somewhat faster), making it possible to run the server
usefully on SMP systems (or even clusters), and therefore potentially
much faster than the speed at which the current server runs.

I don't know if this is what is wanted, but the advantages seem tempting to me.