[MUD-Dev] OpenMUD: bus-based communications

[Niklas Elmqvist]

On Sat, 24 Oct 1998, James Wilson wrote:> 
> On Sat, 24 Oct 1998, Niklas Elmqvist wrote:

> there are two ways I can see to interpret the above:
> 
> 1. modules have various options for communicating with each other,
> which they have to negotiate. ("can you give me function pointers? oh. 
> well, how about RPC?")
> 2. there is an abstract "send message to module" mechanism, which 
> all modules use without knowing what it really does. This mechanism 
> could be implemented in various ways.

I am thinking in terms of the second alternative. The module object
requests a communication channel with a specific module (using its ID or
anything). The core hands it a channel and tells it to "speak through this
thing". The module won't have to know whether the channel is in reality a
function pointer, a proxy object (like your CORBA example below) or a
distributed RPC mechanism.

> > - Messages passed between modules are serialized according to a
> >specification provided by the receiving module. That is, the magic module
> >might say: "I first want a byte containing the spell code, then an int for
> >the level of the caster, then a DB index for the target and caster." The
> >parser module would follow this format when passing messages to the magic
> >module. 
> 
> so everything would be serialized to bytes? or would this only be 
> necessary in a distributed system? why should a system that runs on a 
> single machine take the performance hit to serialize data it could simply
> pass in as parameters? 

The thing is that the modules do not know of each other beforehand and
must communicate in some way. One alternative is to define a preset number
of function interfaces (like in Chris's post) which all modules must
adhere to. Another option is to use serialization, as I suggested, to pack
information into a "free-form" data structure. Oh, and there is no reason
why serialization must be done at both ends -- the receiving module may
know exactly what kind of a struct it expects and just cast the byte
stream to that. For a parser, however, there is no *way* for it to keep
track of the message passing structs of its clients (and there is no
reason why it should, since a parser should be general-purpose and
independent of game), so it would serialize the arguments according to the
wishes of the receiving modules.

> I am having trouble seeing the point of this system. If Module A needs
> to use functionality which resides in Module B, you don't need to
> resort to a bus. Module B can export some symbols, which A can then
> grab and use very happily (with direct method/function calls). If 
> Module B really resides on some other machine, there's still no need 
> for a bus: the process containing A can be supplied with a proxy, B', 
> which pretends to be B but really marshals the calls and sends them over 
> the network CORBA-style. Perhaps there's also a bit of reflection, so 
> A can tell the difference and optimize the way it uses B or B'.

Well, in my thinking, the bus/pipe is an abstraction which collects direct
function calls, RPC mechanisms and CORBA proxies under one mechanism. 
Since we may very well wish to support *all* these ways of communication,
it makes sense to use this architecture. Abstraction *is* good (okay,
maybe not to the point of inefficiency, but I would argue there is not
much added here -- if possible, the bus system will choose direct function
calls).

In addition, as Chris Gray stated in another post, the bus/pipe is as good
place as any for queued messages to wait while they await the attention of
their modules in a multi-threaded system.

> James

-- Niklas Elmqvist (d97elm at dtek.chalmers.se) ----------------------
  "The trouble with being a god is that you've got no one to 
   pray to."
		-- Terry Pratchett, Small Gods