[MUD-Dev] Distributed State Systems

[Michael Tindal]

On Wednesday 01 September 2004 07:38 am, Alex Arnon wrote:

> Are you using a shared-everything, load-balancing server pool, or
> a cluster where every N nodes manage a zone (in load balanced or
> failover fashion)?

Well, thats where I'm unsure.  I never really thought about
assigning nodes to zones, rather, nodes were responsible for
connections, and everything else acting like it would in a
traditional MMO server environment.  I have realized that it might
be in my best interest to completely abandon the traditional MMO
environment (seeing as I've already done that anyhow).

> Anyway, shared-everything seems like a serious bother, and limits
> scalability (unless data is practically always "unshared"). You
> either need to go to the DB (or another node) for data, or cache
> aggressively and hope your data sets are relatively exclusively
> accessed.

That was my biggest concern, scalability.  The connection handling
details allow for the actual connection portion of the server to
scale indefinitely (only mindful of CPU usage and capabilities).
However, the data store has the ability to limit scalability and
also decrease the overall player experience.

> There are other schemes that can be implemented, but in general in
> seems to me that partitioning the world into zones and moving
> objects between them is the most productive method. Some sort of
> interesting handover mechanism might be implementer in case the
> world is supposed to be contiguous, and you might need to
> constrain the number of live objects (mobs + players) in a zone,
> but these are solvable (and in the case of shared-everything, your
> servers will get bogged down with locking in case of too many
> players in the same area anyway - and in other cases too).

What I'm looking at currently is dropping any kind of
overhead-inducing database backend, but more of primitive database
(like you mentioned earlier in your post) with a custom protocol
being used between a specific database node and then connection
nodes.  The protocol will be presented in the form of IPC calls, so
the overhead involved in the actual calls should be minor.  Using
the nodes to manage zones rather than just connections could present
itself in overhead, as the calls to reassign connections scale
upwards as more zones are added and the more people moving between
zones increases.  The overhead involved in keeping zones managed by
multiple zones increases as well.  I guess I should implement both
methods, run some benchmarks, and work with whatever works out
better.

Any more suggestions from people with more experience in this field
is highly welcome.

Mike Tindal
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev