[crossfire] Changing maps from under a running server

[Tchize]

Kari Pahula a écrit :

>I tried replacing maps while the server was running, with less than
>spectacular results.  I ended up with having all the exits leading to
>areas that were not in the server's memory to be closed.  YMMV and you
>might end up with a less broken server state, but basically there are
>no guarantees currently about what will happen.
>  
>
exit are marked closed if corresponding map is not loadable. If you
removed some maps from server, the server would obviously not be able to
load them.

>One possibility to handle this is to open everything under maps/ on
>server startup and just give file descriptors from that pool to the
>server whenever it wants to read maps from there.  The inodes will
>remain open until the file descriptors are closed and it'll be
>possible to replace or even remove altogether the maps while the
>server is running and the server won't notice a thing.
>  
>
What's the point? If you load all maps inode at server startup you'll
risk seriously to hit  the maximum file decriptor / process limit of the
os (there are lots of map files), not to mention the waste of memory
(each file descriptor has quite a good amount of various os datas
associated to it).

>This would make changing the mapsets happen smoothly.  Still, there is
>a need to make the server use the new maps without restarting.
>  
>
If you keep inodes open, here is what will happen
- on unix filesystems, you won't see the new versions of the files until
the server is restarted (no gain compared to stop server, copy files,
start server)
- on windows filesystem you'll get error messages telling the files are
in use.

>As far as I can see there isn't really any way to transparently,
>reliably and automatically transfer players to the new mapset from the
>old one.  The simplest thing to do would be to immediately teleport
>all the players to Scorn (or some other known place) and purge the old
>maps from memory and close the file handles.  But that hardly would go
>well with players.
>  
>
Even if it was possible to change all existing server maps in memory /
cache with a new set, you'll race in other problems when map structures
are changed, mainly of the type player's way back to surface closed.

>An idea I got was to have a DM command (or something like that) which
>would insert an undroppable portal in all player's inventories.
>Activating that would remove the portal and teleport the player to the
>new mapset.  The file descriptors of the old maps would be closed when
>the last player had used the portal.  Perhaps the players could be
>made to gain no exp while on the expired maps to add an incentive to
>vacate them...  But that's details.
>  
>
Player having to manually 'upgrade' their player? That's not something i
would call 'transparent for player'

>Any comments about this before I start writing a patch?  Does this
>sound like a viable plan?  It doesn't sound like the most trivial
>thing to implement...
>  
>
Not trivial, waste of time, prone to bugs, need and active action of
player, os dependant, memory hungry

If you implement this patch, take all necessary step to make it an
activable option, considering the nightmare it can bring to a server owner.

Other suggestion:
just change the maploading process. Currently it does
if (map in cache and not reset)
    load from cache
else
    load from original file

try this
if (map in cache and map date >= original file dates and not reset)
    load from cache
else
    load original file

Ho and btw, i have always wanted to be able to define 'reset block' that
is a set of map that reset together (to prevent entrance reset in quest,
leading to 'help am stuck, i need a dm'), that might be usefull.

>_______________________________________________
>crossfire mailing list
>crossfire at metalforge.org
>http://mailman.metalforge.org/mailman/listinfo/crossfire
>
>  
>