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

[Bruce]

On Thursday, November 18, 1999, Mik Clarke wrote:
>"Bruce Mitchener, Jr." wrote:
>> >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.


That would appear to be a rather naive implementation.  I'd like to think
I'm not that stupid. :)   I wouldn't break it out at the command level, but
there are various subsystems which can be broken out and segregated.

>> >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.


That just gives AI an advantage over players and requires them to be in the
same process space as the rest of the system.  As for your efficiency point,
I don't plan on sending text messages to any of them.  World events will
travel to any interested and connected server and to the clients.
Presentation of the world events or processing of the world events is a
client issue.  With proper authorization, clients will be able to produce
various world events as well.  This would allow even stuff like a weather
system to be separated out into a rather specialized 'client'.  AI wouldn't
suffer any disadvantages that I can tell by doing it this way over having it
in the same process space.

 - Bruce





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