From: michael@gandalf.moria (Michael Haardt)
Newsgroups: comp.os.minix
Subject: A few remote procedure call questions
Date: Sun, 13 Dec 92 12:17:59 +0100
Organization: An old and gray machine, somewhere in Moria.
Distribution: world
Reply-To: u31b3hs@pool.informatik.rwth-aachen.de (Michael Haardt)
NNTP-Posting-Host: messua.informatik.rwth-aachen.de
Keywords: RPC, remote procedure call

A few months ago, there was a nice kernel discussion in this group.  I
read some things about RPC in between, and I like the concept of remote
procedure calls a lot.  However, all I read explained how RPC is used,
but not how it is implemented.

I don't like timeouts for RPCs, but having the kernel generate an answer
message if either the addressee is invalid or busy (not listening for
RPC requests).  If the addressed process doesn't listen, it is up to the
caller to send the RPC again or treat it as an error.  Of course that
means that I expect reliable connections.

I understood the RPC concept to be synchronous, which means that a
process can be in one of the following states:

-  busy
-  listening for RPCs
-  busy with calculating an answer
-  waiting for answer of a sent RPC
-  busy with calculating an answer and waiting for answer of a sent RPC

Is that correct?

I think that not using RPC queues for non-listening processes would
result in bad performance because RPC are getting sent again and again,
but queues can overflow, and they will do for sure if a process doesn't
intend ever to listen to RPCs.

The synchronous concept doesn't allow a process to run in threads and
managing its own queue, because after listening for one RPC it first
has to be answered.  That brought me to the idea of redirecting a call.
That way, a client (a) can run in threads (b,c,...), which all have
ports to the kernel.  Other processes always send RPCs to (a), which
redirects them to (b,c,...) depending on which one is listening.
Redirecting means, that now (a) can again listen, because (b,c,...) will
answer that call.  Sending out a redirected RPC is equivalent to
answering it concerning the above process states.  This method allows a
threaded filesystem to be written, and for each filesystem thread to let
a device driver process answer a call directly back to the client.  That
way, traffic is reduced a lot.

Now tell me, did I misunderstood RPC completely, or does the RPC concept
already contain redirection and I only didn't see it, or how is a
threaded filesystem supposed to get implemented?

Do already existing systems like Amoeba use queues for calls?  Do they
have threaded filesystems?  What is done with overflowing queues, in
case queues are used?

I first want to get these (and perhaps more:) questions answered, if
things turn out not to be too complicated, perhaps I will write a small
kernel only containing process management (create, kill), memory
management (alloc, free) and communication (delivering RPCs)
capabilities to play with it.  Such a microkernel should be very small
and not too hard to write.  To keep things simple for the beginning, I
will not care about routing RPCs in a distributed system yet.

Any comments?

Michael "wondering about RPC"

PS: I know, this isn't related to Minix, but this group is read by
    kernel hackers, so ... :-)
Newsgroups: comp.os.minix