[MUD-Dev] [TECH] monitoring RMI-type systems

[brian price]

> From: Bruce <bruce at puremagic.com> 

> I asked this question about 3 weeks ago and while it spawned some
> other thread, I didn't get any answer, so I'm willing to be
> stubborn. :)
 
> One model of distributed communication between objects is that of
> RMI or CORBA, where operations are intended to be transparent.  From
> the syntax of a method invocation, you can't directly tell that a
> distributed operation has just happened.
 
> Other models make that much more explicit or don't even use the
> method call type model for doing distributed operations.
 
> Since the costs between an in-process vs. remote method call as well
> as the potential failures as so vastly different, the former model
> strikes me as being dangerous in actual use.
 
> So, my questions:

>    Do any of you use a distributed system at all?  What can you say
>    about it?

I'm currently working on a MORPG system which uses a form of RMI for
client/server communications.  The system uses object streaming for
all client/server data exchange and has only four objects upon which
remote methods may be invoked, namely; client, player, server, and
character.

Client side the system can invoke methods upon the server or
corresponding character objects.  Server side the system can invoke
methods upon the client or corresponding player objects.  The client
and server objects are used for out-of-game tasks, while the player
and character objects are used for in-game tasks.

Since the objects involved are limited in number and well known, any
performance issues are reduced to those associated with the encoding,
transmission, decoding, and dispatching of the method, argument and
return objects.  A programmer using this system never 'accidently'
invokes an RMI call.  It is safe to assume that *all* calls to one of
the RMI capable objects will result in an actual remote method
invokation.

In this system, there are no [in][out] parameters.  All method
parameters are [in] and only the return type (if not void) is [out].
Since the system uses object streaming and all parameters (and return
types) are non-primitive objects, this simplification imposes no
serious limitations.

When performance is a critical issue, it is best to avoid invoking
remote methods which have a return object.  At the RMI system level, a
method with a void return is a 'fire and forget'
(non-blocking)operation; a method with a return object must block
until the remote system has recieved and processed the method call and
successfully transmitted back the return object.  This may seem a
serious drawback at first but thus far I've found that it works well
conceptually with an event driven system since, in most cases, no
return objects are required.

Brian Price
-= have compiler, will travel =-


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev