NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/os/minix/4918

Internet Message Format | 1992-12-14 | 5.1 KB

Path: sparky!uunet!gatech!news.byu.edu!hamblin.math.byu.edu!sol.ctr.columbia.edu!caen!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!natinst.com!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail
From: [e-mail] (InterNet News)
Newsgroups: comp.os.minix
Subject: Re: A few remote procedure call questions
Date: 14 Dec 1992 12:54:08 -0600
Organization: Armstrong Lab MIS, Brooks AFB TX
Lines: 100
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: hrd769.brooks.af.mil
Keywords: RPC, remote procedure call

In article <[e-mail]> [e-mail] (Michael Haardt) writes:
]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.
]

  Kind of depends on the process, I would think.  If the addressed process
died and we have an answer (or question) for it, we pretty much out of luck,
right!?  If we were the kernel, and we had a system process we wanted to answer,
and it died, things are about to get out of hand anyway, as a rule.  User
processes die all of the time; we would just dump the message.

]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 have gotten a little bit different understanding of them, in that they
are asynch.  In spite of that, the five states seem to cover all of the
options.

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

  Wouldn't we implement some kind of 'can't listen right now' sentinel/flag?
Or when a server is not available (not listening), we mark the node as 'dead'
and redirect to another source of service.  We could check back (or have it
interrupt) when it is ready to listen again, and start using the node as a
server again.

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

  Let's look at an example.  I have machine a running as my file system,
and machine b operating as my memory.  They are all connected together by
TCP/IP.  Machine c is on the net, and contains the kernel.  Machine c needs
a block of memory; it goes to machine b for it.  Machine b has, as it's
processes, a memory manager that uses a client (ba) that redirects all
calls to a queue.  processes (bb, bc, and bd) all are memory allocators.
We allocate the memory using one of the b[c-d] clients.  These clients could
ALSO be on other machines.  The queue would be FIFO, but could physically
reside just about anywhere.  Remote Process Calls generalized to the max, I
think.

  Of course, it isn't likely that we would do something like this (except
maybe for an NFS or something) but it is conceivable.

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

  I like it.  This would really free up the processes to do their thing.
Combine this with the message process that Minix already uses, and I think
we might have something here...

]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 ... :-)

  Oh, but it is in such a neat kind of way.  If the message method we use
in Minix now were expanded to include the RPC concept, we could set up a
cluster of 8088's, each responsible for some feature in the kernel...

WOW !!!!!!!!

I'm just going to set down for a while a dream on that..

TSgt Dave Burgess