[MUD-Dev] Architecture (Cell Rebalancing)

[Peter]

"ceo" <ceo at grexengine.com> wrote:

> 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

that's the matter om implementation. and payoff of modularity.  if i
would hand-code something in assembler, it would take me looong time
to do, but with modular design, it's just the assemply of modules.
and when we are talking about _large_ systems, then the time
matters. even if you need more hardware to run it.

and when talking about mmog systems, if you do one, there isn't many
chances you'll sell it to 1000 customers. so, it's ok if it needs
little more hardware, if you have saved half year of developement
and avoided 1000 bugs.  with scalable (good) design, you should be
able to add a server to off-load the whole system. with bad design,
even that would not help you.

> 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

of course it is. even when inra-server latency is measured in tens
of microseconds (be if numa/other san) or hundreds (be it ethernet),
it will quickly add up based on how many intra-server communications
are needed.  the best would be to run it on shared memory system,
where such latencies are minimal. but that would be expensive. (in
telecom, we are doing that) so, you have to design well and when
actually mapping the design to the HW, you should be carefull.

> 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

depending on the design approach you take. top-down or bottom-up? i
like to combine them, first do top-down, and then redesign it again
all with bottom-up (if needed = if project realisation is probable)
the bottom-up design takes more time/work, is better, and is not
always needed. (if you can see even from top-down design that the
project would be no good)

> 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

WS is related to virtual memory of a process, isn't it? that's way
too far for me yet.

> together in the abstraction. ISTR JC spoke a couple of times about

who is ISTR JC?

> dependent working sets on the night before the MDC (in relation to
> a dicussion on geographical partitioning).

any links/memories of that speech? never heard that before.

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

reading easines for human is only the visual/graphical
configuration. if the design is right, then the partitioning will be
right and the connections will be on proper places in regard to
endpoints.

The trouble with many architects is that they start to program too
soon, in too detailed areas and the result is no good then. i belive
Jessica M has described that in her mmog book. i just want to avoid
that. :)

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