[crossfire] Map cache

[Anton Oussik]

On 8/26/05, adam ashenfelter <
     
     aashenfe at gmail.com
     
     > wrote:
>
     
      On 8/26/05, Mark Wedel <
      
      mwedel at sonic.net
      
      > wrote:
     
     >
     
      >
     
     >
     
      >
     
     >
     
      >   Better long term would be for each map to have its own thread.  With multi
     
     >
     
      > core/thread cpu's, this makes more and more sense.
     
     >
     
      >
     
     >
     
      >   However, that requires some prety significant changes.  First being that any
     
     >
     
      > function that declares any variables as static is not thread safe.
     
     >
     
      >
     
     >
     
      I agree, but what about multi process?
     
     
That would require huge changes, but is actually a very good idea. If
done really well it could even introduce load balancing where maps
(processess) are transferred from busy servers to more free servers as
needed.

On a side note having a central dispatcher would be a design fault as:
  1) It is a HUGE (and I can not stress enough how big the HUGE is
there) bottleneck and will slow the whole thing down to the speed of
I/O of the dispatcher
  2) If  the thing goes down (and it will go down) all other computers
participating in running the server would become orphaned. If the
server is modified in a more flexible fashion one node going down
should not be critical to all the clients not currently on maps
governed by that server.

This is the scheme I propose for a distributed set of servers:
First server to come up runs like an ordinary server.
All other servers connect to an already known server, get a list of
servers and their loads.
A new server then takes half of the maps governed by the busyest
server (servers would need to somehow measure how busy they are,
either themselves or by election by other servers) and associates
itself with all exits to the server, and transfers all players that
are now governed by the new server.

The new issuses to consider here would be player transfer and general
server-to-server communication. Servers would need to communicate to
each other everything a player is able to hear (deaths, says, chats,
joins, leaves, etc), as well as be able to migrate players when they
travel between servers, and agree on who controlls what area.

This also brings up the question of trust, as it is a bad thing to
allow a malicious player (with perhaps modified maps) to smuggle items
into the game by connecting their own server.

This general approach does have an advantage of not needing to be
tread-safe though - if it runs too slowly just add another server :)