IPC in MOOSE

[Peter Mueller]

Hi,

I've already started a private discussion with Gary about his IPC
ideas. In my opinion one should specify the design of IPC in a more
higher abstract level. Don't start discussions if it is efficiently 
programmable or whatsoever. It's specification time: Let's first define
what we want and then see how we can get it.

(I would prefer the term remote object invocation (ROI) and not IPC for
discussion on how remotely access an object. To Fare: "remote" in this
context are all objects, which are not within an application's scope and
which location must be found (see below). And it is not a MicroSoft term.)

>    This is an overview of my vision for processes and interprocess
> communication in the MOOSE system. It is far from being a complete
> specification, and I encourage discussion of the various features. I
> have intentionally left out any implementation details or actual
> example interface code so that we can decide on the abstract model
> first and move on to the implementation once the model is ironed out.
> 
>    Entities in the MOOSE system are referred to as 'objects'. The
> interface to an object is composed entirely of 'methods'. One object
> communicates with another by 'invocing' a method on another object.
> Invocation is accomplished through Remote Procedure Calls, or 'RPC'.
> An invoced method is called a 'thread'.
> 

I think, that's too deep. Let's simply say, that an object must be able
to invoke another object's method. (I don't like to mention how this should
be done, via RPC or not.)

>    Objects represent protected units of functionality in MOOSE. With
> the exception of inheirited (non-virtual) base class code (libraries),
> each object has a completely private, non-shared address space. The
> kernel is reponsible for scheduling objects and providing resources as
> needed. Each object has a specific protection level which determines
> how the object's threads may directly modify the system hardware.
> 
>    An RPC call will contain information such as a remote object name,
> the remote object's method name, permission information, and a set of
> arguments to the method. The invocing thread is blocked, the message is
> delivered to the destination object, the object executes the method
> with the given arguments, and passes the return value (or error code)
> in a message as a reply to the calling thread. Note that passing
> pointers isn't useful, since objects have disjoint data spaces. There
> are, however, techniques to improve performance when passing large data
> items.

That's again too deep. Naming should be done by another object, eg. a 
NAME_SERVICE. This must exist, because objects must be able to publish 
themselves or their methods to the outer world. Thus, an object X which
want to be published invoke a methods of the NAME_SERVICE, which makes X
known within the NAME_SERVICE's scope:

+---+              +--------------+
| X |---publish--->| NAME_SERVICE |
+---+              +--------------+

If an object Y wants to use X it first must determine X's location. Therefore
it asks its NAME_SERVICE, which returns X location:

+---+                           +--------------+
|   |---ask for X's location--->|              |
| Y |                           | NAME_SERVICE |
|   |<---return X's location----|              |
+---+                           +--------------+

Now Y can simply invoke a method from X:

+---+             +---+
| Y |---invoke--->| X |
+---+             +---+

With this design it is possible only to contact published objects. More: You
have to contact the right NAME_SERVICE to get a desired object's location. 
Think of several applications (which are O B J E C T S), which all have their 
own NAME_SERVICE available. Several objects with the same name may coexist
even with different functionality but the application's local NAME_SERVICE
secures, that the application is only able to invoke methods of well known
objects. 

Of course it is possible to "link" NAME_SERVICE objects. So it is possible to
create hierachical or other name scopes. If an object's location cannot be
resolved within the first (ie. smallest) scope the next higher NAME_SERVICE
is automatically invoked.

What I currently left out is, how an object received knowledge of "its"
NAME_SERVICE. (Or to be precise: Which NAME_SERVICE provides the knowledge
of the desired object.) If you want, I can try to present you a design
idea.



>    The thread is the basic unit of execution within an object. A thread
> can invoce a method of another object via an RPC. The calling thread is
> blocked until the call is completed, but the other threads are allowed
> to continue. The call is received by a thread in the target object that
> waits for calls to that particular method. Threads can create other
> threads to execute while others are blocked. This allows the object to
> continue processing while waiting on the result, while maintaining
> procedure call semantics.

That's again too deep for the first ROI specification.

> 
>    An object is created by an RPC call to an object with access to the
> scheduler and resource allocator. An object with such access may also
> destroy an object by descheduling it an deallocating its resources.
> Each object will have an initial set of object names. This will
> generally include the name of an object that holds the names of other
> objects. 

Hmm, what does object creation have to do with ROI? (BTW: In my opinion
an application which cannot receive access to an object, simply create an
instance of a new one. Then the object can make itself available via the 
application's NAME_SERVICE or a predefined one. Of course the application
object already know the object's location and can invoke methods immediately.)

> Each object should include a method to determine the names of
> its other methods.

NO! Publish all methods which should be accessable by other objects to the
NAME_SERVICE! Seperate the services (provided by objects) and it's management
(provided by NAME_SERVICEs). Without such separation each time you include
a new service you must also change the determination method. Don't mix up
services and their availability.
 
Cheers,

Peter