Questions about different types of KeyKOS IPC

[William S. Frantz]

> * How useful and common is FORKing on a start key?  Given that the sender
> may block anyway until the message is delivered, no additional security is
> provided.  

FORKing a start key is the standard form of fork.  By having a domain that
is specifically used for the purpose of being available (I suppose it could
be called a promptness server, but is currently called a forker), you have
assurance that the fork won't block.

As a note, KeyKOS encourages the technique of throwing domains at a problem.
The view most other systems have is that the set of servers is somewhat 
static.  KeyKOS style says if you need a server with specific characteristics,
build one out of existing servers with some glue to meet your needs.


> Given that, the equivalent of this operation can be implemented
> by doing a CALL on the client side and the server immediately doing a FORK
> on the client's resume key once it receives the request.  So the benefit of
> FORKing a start key seems to be at most a performance issue.  What is your
> experience on this?  

But this approach would require the server to know the client wanted
paralelism.  Most KeyKOS servers were designed to be called with a request
and return an answer.  If the client needed parallelism, the client was
responsible for doing the fork.


> Does overall system performance benefit significantly
> from this feature?

Well, clients that don't need parallelism, don't pay for it.  I don't 
think this is a big deal either way for performance.


> * Similarly, how useful and common is RETURNing on a start key?  This seems
> equivalent to FORKing on the start key followed by RETURNing on no key, so
> again it appears to be merely a performance issue.

Indeed these are equilivant.  However, the orthaginality of being able 
to do any operation to any key is elegant, and keeps you from having to
define what happens when you attempt an "illegal" operation.  It also
helps with information hiding (e.g. what kind of key is it anyway).
Some "interrupt driven" clients (e.g. a UNIX simulator) pass services
that will accept one a start key so they can be available for other
operations while the server is processing.


> * Finally, how useful in practice is the ability to FORK on a start key and
> pass an arbitrary other key in the key slot normally occupied by the resume
> key generated by a CALL?  

It is used in OS simulation and other cases of parallelism quite commonly.


> In other words, how useful is the ability to
> "spoof" a server into thinking it was CALLed, when in fact the "resume key"
> it received may be to some other thread, and may not even be a resume key?

You can't spoof a server that cares about start vs. resume key.  And all
generally avaliable public servers care.  (However many of them are
multithreaded and only the specific clients thread will block, so they
will accept a start key in the 4th slot.)



> Again, this does not seem to give the client any more protection from the
> server, since it may block anyway if the server is busy; and furthermore,
> it seems to burden all servers that don't trust their clients with the
> necessity of explicitly checking every resume key they receive to ensure
> that it's actually a resume key.  

We didn't worry about protecting the client, since the server could 
always decide not to return.  We did worry about protecting the server,
so we provide a kernel implemented operation (so it doesn't add an 
extra invocation) which checks that the key is a resume key and iff
it is, invokes it.  (If it isn't, it discards the message.)


> So supposing the FORK operation on a start
> key did not allow anything to be passed in the "resume key slot", how would
> that affect typical KeyKOS applications and servers?

A few operations would require an extra domain to get around the
restriction.

-----------------------------------------------------------------
Bill Frantz                   Periwinkle  --  Computer Consulting
(408)356-8506                 16345 Englewood Ave.
frantz@netcom.com             Los Gatos, CA 95032, USA