[MUD-Dev] Architecture (Cell Rebalancing)

[ceo]

Rossmann Peter wrote:

> It was overengeneered.  I have tried to draw new design here:

>   http://w1.860.telia.com/~u86015984/MMO-Grid-Cluster-v2.jpg

> all elements are actually arrays of the same elements.

That's a nice little design for a theoretical "game server". But
distributed-system design is not as simple as that. The easiest
analogy that comes to mind is the OSI 7-layered comms model. Yeah,
it's a great way of abstracting the functions, and it's a lovely
simple way to understand and reason about existing systems.

But it's not helpful if you're trying to build fast networking
systems (However: the OSI model has been around a looooong time;
I've been using it for over a decade IIRC, and by now I'm sure
hardware and networking systems have advanced so much in terms of
performance etc that actually it's OK to implement the 7 distinct
layers separately).

In network-design, 7 layers always meant 7 levels of parsing,
message passing, and indirection. If often meant 7 levels of
buffers, and 6 inter-layer interfaces - all of which added
latency. Bandwidth was often leeched by all that indirection too
(although improvements in handling of large amounts of data and
implementation of things like zero-copy data-transfer through the
layers got rid of many of those problems, I believe).

In a clustered system, latency is still a problem (note: generic
systems rarely worry much about latency - this is one of the ways in
which games-systems are fundamentally different). You can almost
look at it and say that latency is the only problem - perhaps
everything people find hard to implement in a cluster could be
implemented fairly straightforwardly if you were prepared to endure
long processing-time-per-request (for instance, all your concurrency
issues would be easy to solve - largely by just serializing
everything ;)).

I'm not attempting to argue against the use of abstraction in
server-design - but the abstraction has to come from a much
lower-level than isolating systems (which is what your design
currently does). You want to be abstracting things that work
together in practical terms e.g. by looking at working-sets (c.f. a
google search for "working set" if you don't know the term) and
making sure each clump of related/non-independent data is grouped
together in the abstraction. ISTR JC spoke a couple of times about
dependent working sets on the night before the MDC (in relation to a
dicussion on geographical partitioning).

Otherwise you have a design that is easy for a human to read on
paper, but practically impossible to implement.

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