[MUD-Dev] Languages for MUD drivers

[Ian Macintosh]

    > From: Greg Miller
    > Sent: Thursday, 18 November 1999 06:47
    >
    > Ian Macintosh wrote:
    > > Distributed processing support can be handled by
    > running multiple
    > > processes and interconnecting them.  I've always
    > thought that this is
    > > a better way of handling large systems and a large
    > number of users.
    > > ie, segment areas (zones) onto different servers and
    > link them.
    >
    > 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.

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.

By segmenting functionality, I'm talking about taking certain portions
of the program known to eat CPU, and putting that on one or more
servers.  To go totally haywire on the concept, think of the
following.

Server A.   Handles player network connections, traffic, command
parsing and player state
Server B.	Controls part 1 of the virtual world, with static object
(fountains, stones, doors) plus the mobiles, but no mob code
Server C.	Controls part 2 ... as above ...
Server D.	Controls part 3 ... as above ...
Server E.	AI for X mobiles (mob code)
Server F.	AI for X mobiles (mob code)
Server C.	Path finding code
Server D.	Combat handling code

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.

Of course, I'm not talking about a trivial system in this example, but
rather one capable of handling over 1,000 simultaneous players.  For
something more in the line of what I'm doing at the moment, one server
with 4 separate processes does the job.

The reason why I believe this is better than using RPC or whatever to
load balance based on events, is that I can't get away from the
requirement that one system has to be the master, or own, a particular
piece of the MUD.

i.e., Server B handles Midgaard, and as such, if *anyone* or *any
server* wants to know the exact state of Market Square, it must find
out here.  If there are two servers possibly handling the same piece
of real estate, who's version is the right one?  Likewise, Server E
controls the Grand Mistress of Magic sitting on her throne in the High
Tower of Sorcery.  If you want to know her status, you find that out
by querying Server E.

I hope I make some sense :-)

Regards,

Ian Macintosh.




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