ORG, IPC, pem 05/17/93

[Peter Mueller]

Hi, 

this is actually a reply to a mail with subject "Re: Where IS everybody". I
think that the new subject line will make things much more clearer. And now,
for something completely different ... 

> =>Maybe there's a possibility to get things started. Mmh, I think we all do agr
> ee,
> =>that the basic mechanism which must be provided by the kernel (Moose) must
> =>be interprocess communication. (Or: message passing).
> =>
>    Absolutely.
> 
> =>Therefore we have to create a module, which provides an interface with three
> =>primitives, namely:
> =>
> =>	send(destination, message)
> =>	receive(from, message)
> =>	reply(to)
> =>
> =>I suggest synchronous ipc, because it seems to me to be the basis of
> =>any other ipc types.
> =>
>    I used to be of this opinion, but I've changed my mind somewhat. I
> still think that the basic *user* level IPC mechanism should be based
> on blocking RPC, as you have described. However, there are some
> advantages to building synchonous calls out of asynchronous calls.
> (i.e. asynch_send(dest, msg) -> reply_id; block(reply_id)) For example,
> a user-level thread package would be much easier to implement in this
> scenario. On the other hand, advances in technology may allow us
> eventually to use normal function calls to implement IPC, which is
> basically blocking the caller untill the function returns, so we should
> make it possible to use such a technology as it becomes available.

Let me comment on this: 

1. A user should, of course, use blocking RPC (which meant ROI). This is the usual
   way to communicate in an OO-environment. (Ok, but to be honest: I suppose that
   their will be some low-level user who uses low-lewel languages and who will
   call IPC primitives directly ... but that's for the system people :-)
   Nonetheless their must be provided mechanisms within the kernel with which ROI
   can be provided. ROI is a more conceptual view of communication. As is RPC in
   common procedure oriented environments. RPC also is only a conceptual model, where
   the IPC stuff is hidden by stubs, which are in turn automatically created.
   We have also to create such "stubs", though they will actually be some kind of
   communication objects. They should handle all necessary stuff to invoke a remote
   method.


2. Now for the difficult part. I do not agree to include asynchronous calls within
   the kernel. Here comes my reasoning.
   Asynchronous communication requires additional overhead. Their must be buffer
   allocation, management, reallocation, etc. This will slow down the whole system!
   (This is proved within some existing systems.) Additionally the kernel will be much
   more bigger. Management will be much more complicated, hence, overhead.
   Well, I know the user is always asking for asynchronous IPC, because it is a much
   more "natural" way to see communication. Of course, there is an alternative. It's
   OO! If someone definitely wants asynchronous IPC he/she should get it with the 
   mechanisms of OO. See, that asynchronous IPC is a specialization of synchronous
   IPC: It is actually specialized in buffering.
   A second alternative is to provide a kind of "buffer manager", which is, of course,
   a server object. If you want a buffered communication, simply install a synchronous
   communication channel to the buffer manager. This manager will then setup a 
   synchronous communication channel to the real destination. Now we have a asynchronous
   communication channel from source to destination, where the buffer manager lays
   in between. BTW: This will give you the freedom to provide several different
   buffer management policies. You can choose your own buffer size. And that's all on
   the fly (same is for the above OO solution).
   On the other hand a user who wants to get the whole out of the system is not 
   disturbed in doing so. He simply can avoid a massive communication overhead in
   using the "basic" synchronous primitives (which are very very fast :-).

>    So I would advise making IPC asynchronous at the system level and
> providing standard library (or langauge-imbedded) functions for
> synchrounous IPC. When the secure function call technology appears, we
> can simply change the library function (compiler) to use the new call.

And I say make it vice-versa: Provide synchronous IPC at system level and make a
standard lib. for asynchronous IPC. Yup, and: BEWARE, I'm a tough guy to argue with
in that subject ... grrrrrr >:-|

> 
> =>Where we still have to get to an agreement is:
> =>
> =>o How looks a destination address? 
> =>  Should it look like this: (machine address, object id, method id)
> =>  or only like this: (object id, method id)
> =>  or like this: (machine address, process id)
> =>  or: ???
> =>
>    I don't think including the machine address is necessary, and not
> particularly desirable as part of a system that may very well be
> stand-alone. Therefore, (object id, method id [, authorization])
> would seem to be the logical answer. To support object server
> objects, I would suggest a two-level object id (external and
> internal), or possibly object id classes (analogous to Internet
> network classes and subnets.) This would allow for addressing either
> entire system objects or smaller objects managed by the larger system
> object with no change in call syntax. Objects on remote machines
> could be accessed via a network object server object that does
> translation and forwards calls to a network object server object on
> the destination machine, which does the actual call.
> 

Ok. That's one design decision. Then we should provide an address object. I think
that we can provide a mechanism with which a specialization into several address
layouts can be made. (I mean, that if in the far future one want to extend Moose
to a distributed OS the addressing mechanism can simply be adjusted. Got to think
this over, anyway ...)

Now I've got a question: An address of (Object id, method id [,authorization]).
Why is authorization necessary? Isn't it enough that, IF an object have the address
(object id, method id), THEN it is automatically authorized to call the method? Then
authorization is separated from the objects. As the actual address is grabbed from
a (what's it name DIRECTORY? and: where's the glossary?) Object, why not providing 
authorization tasks within that object?

You are then again free to provide several security policies on the fly by choosing
the appropriate directory object. So you can range from a system with no security at all to
a full secured system. Of course, the request for receiving an object's address must
hold a kind of ticket. This ticket should identify the owner of the request and its
permission rights.

> =>Let me know what you think. If you want, I can try to write a draft about
> =>the IPC interface. I will wait for Dennis' next spec's because it will
> =>give a us a basis. Ok?
> =>
>    Sounds good to me.
> 

Dennis? Your work! :-)

>                                        Gary Duzan
>                                        Time  Lord
>                                    Third Regeneration
>                         Humble Practitioner of the Computer Arts

Peter