Questions about different types of KeyKOS IPC

[Bryan Ford]

I'm interested in hearing some experience-based reflections on some of the
features of KeyKOS IPC.  In particular:

* 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.  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?  Does overall system performance benefit significantly
from this feature?

BTW, note that QNX's IPC system is very similar KeyKOS's in terms of
blocking and waiting mechanics, but one major difference is that it
provides no equivalent of FORKing on a start key - clients can only CALL
servers.

* 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.

* 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?  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?
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.  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?

Thanks!

				Bryan