Distribution schemes (was Re: [MUD-Dev] Languages for MUD drivers)

[Mik Clarke]

"Bruce Mitchener, Jr." wrote:
> 
> Ian Macintosh wrote:
> >    > I've always thought this was an extraordinarily poor
> >    > way to handle it...
> >    > Unless you have a truly enormous number of players,
> >    > don't you end up
> >    > shifting areas from server to server as players and
> >    > groups move, in
> >    > order to achieve load balancing? Wouldn't event-based
> >    > distribution work
> >    > much more cleanly?
> >
> >I'd agree with that Greg.  But that is really dependant on how you
> >design your software.  In the first place, I am, as you say, trying to
> >load balance, but not to the nth degree.  Rather, I want to find
> >logical breakpoints where I can split the 'world', and thereby achieve
> >a fairly equitable load sharing.  Of course, what this means in the
> >normal Aber/Diku derivatives that we all seem to run, is that you
> >would put different zones/areas on different servers.
> 
> This would fall victim to the phenomenon of 'flash crowds' or 'stampeding
> herds' or whatever it should be called.  With this type of static
> distribution scheme, you can run into some trouble if a large number of
> users (or objects, or whatever) decide to go visit some area on a single
> server.

I would favour an approach that segments the world like this, makes the
world on each server self sufficient and makes it fairly hard to move
between worlds (including a 'world full' mechanism to stop people from
entering when it's near capacity).  This allows for interconnected, but
distributed servers and gives efficient processing as each server has
everything it needs.
 
> >What you really should do though, to my mind, is segment the
> >functionality.  Now perhaps that is what you are alluding to when you
> >talk about event-based distribution, although I read that as saying
> >that the exact same command could be processed on any particular
> 
> >server, depending on that servers load at the time.
> 
> I tend to think about it roughly this way and with the use of events, but I
> need to put a lot more thought into my current set of thoughts.

Uuugh. Yuk.  So every say statement goes through server 1 and every
spell
cast through server 2 and every move through server 3?  I think this
would very quickly drown from the amount of ineraction required between
the servers.  Bandwidth and network latency are the bug bears.  Avoid
all designs that have any sort of heavy dependency on network traffic
and remote processing during the processing of commands.

If you like, think of a mud as a virtual CPU that the player is
connected
to.  They send a transaction (a command) in, the mud processes it and
then sends the response back plus asynchronous output to other players.
Having it go and scurry around over TCP/IP links between multiple
servers
is going to kill your response time.  Each server needs to be as
self-contained as possible  (this also help avoid problems when one
server crashes - it just takes out one super-zone, not all spell
casting).
 
> >You could of course split those tasks any way you like, but the
> >concept should be clear from the example.  What you really want to do
> >is ensure that any particular part of the project can be handled by
> >one or more servers in your server farm.  If you do that right, you
> >don't need to concern yourself too much about where the right place to
> >split would be.  If you find you allocated too few servers for the mob
> >AI for example, you just add another server and split them into 3
> >groups instead of 2.
> 
> Why does AI get treated any different from any other client connected to the
> game?  (Making a lot of assumptions: clients aren't accessing world via flat
> text that they just display, like telnet; that there are clients; etc).

It's imbedded, there's no network latency, they have direct access to
all program objects and variables.  AI can be a lot more efficient than
a client as it can directly process the world events, not the text
messages that result from them.

Mik



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev