[MUD-Dev] Re: PDMud (was Re: Bruce Sterling on Virtual Community goals)

[ApplePiMan at aol.com]

At 10/23/98 1:40 AM Niklas Elmqvist (d97elm at dtek.chalmers.se) altered the 
fabric of reality by uttering:

>> Efficient modules isn't enough to make the whole system efficient. You
>> also need efficient intermodule interaction. You don't want to be
>> spraying lots of random things all over. The modules should advertise
>> what they can handle, and the associations should be made once, at the
>> load time of the added module. Then data (commands, output, etc.) flows
>> in a directed manner. We want pipes, not a water sprinkler!
>
>Hmm, you're right. But we also need some way for new modules to broadcast
>their capabilities at the load time. So the water sprinkler at load time,
>then pipes henceforth. Maybe we could use a handshaking protocol like
>this:
>
>1. module is loaded into memory, either at boot-strap time or through
>	other means (an admin adding new functionality to the game or
>	replacing buggy parts)
>2. module connects to the broadcast channel and bellows "here I am, and I
>	am capable of this..."
>3. existing modules will silently process the broadcast message (everyone
>	listens to the broadcast channel) and may decide to ignore the new
>	module 
>4. if not, the interested modules request a pipe/channel to the new module
>	from the core, which they receive 
>5. the modules may, if applicable, send information about themselves
>	through their new pipes to the originating new module (if the new
>	module for example is a new parser which requests grammars from all
>	command handlers)

Through no fault of yours (but rather my tentative grasp of technical 
issues), I don't quite follow that; so I may be saying exactly the same 
thing as you in what follows. If so, forgive me for restating it in my 
own words.

The way I see it working is that a module broadcasts a "here I am" 
message when it first comes online. The "here I am" message is *always* 
broadcast to every module. When a module receives the "here I am" 
message, it decides whether it wants to listen to the new module. If it 
does, it calls the new module's AddListener routine with 'this' (the 
listening module) as a reference, and the new module adds the listener to 
a linked list of modules it will broadcast state changes to. You'll still 
have a degree of (technically) unnecessary traffic; but it's much more 
efficient than the "water sprinkler" approach.

Such a system could be fine-tuned by adding the capability for a listener 
to specify "suites" of events they're interested in being notified for 
(cutting down traffic by having the broadcaster not send changes the 
listener is not *specifically* interested in).

>I am thinking that we could use one-to-many pipes here... Or maybe even
>many-to-many pipes (not sure about that, though). That is, using the above
>handshaking sequence, a parser module would get a single output pipe which
>branches out to all command handlers since they are all interested in the
>parser "in the same way". It would also receive an input pipe from the
>network I/O module. This way, the parser would receive raw input from the
>input pipe, parse it and then emit the processed data to the output pipe,
>not caring who is listening. The processed data is propagated to all 

Seems to me (if I'm understanding you correctly) that's still an awful 
lot of traffic going to modules that don't want it and can't use it 
(since the data is propagated to all). Swarming traffic will eat you 
alive...

>Maybe one-to-one pipes would be better since it would minimize the traffic
>flow and "water sprinkling". However, it would also force central modules
>such as the parser to become much more complicated since they would have
>to keep track of where different pipes lead and what to send on them. Not
>sure about it myself.

Let each module keep track of its own pipes.

>We will also need a defined sequence for modules to disengage themselves
>from the module community and be unloaded. 

Yep... but a module could just send a "going away" message to each of its 
listeners. Then the listeners are responsible for clearing any pending 
transactions, and then shutting down the pipe by telling the broadcasting 
module to remove 'this' as a listener. Once the module's linked list of 
listeners is empty, its safe for it to go away. 

-Rick.



---------------------------------------------------------
Rick Buck, President and CEO  <mailto:rlb at big-i.com>
Beyond Infinity Games, Inc.
See you in The Metaverse! <http://www.big-i.com>