All of you know how a simple procedure call
works. There is a caller you have a process in
which all the functions are being compiled together and
linked together, made an make an executable. And so when
a caller makes a call to the callee, it
makes a call passing the arguments on the stack. The
callee can execute the procedure. And then a return
to the caller. So this is your simple procedure call.
And the important thing is that all of the interactions
that I'm showing you here is happening at compile time. All
of these things are being done at compile time. Now
let's see what happens with remote procedure call. You know in
principle a remote procedure call looks exactly like this picture.
That you have a caller and a callee. SO the caller
is making a call Executing a procedure, and returning. So
that's what is going on in, in a remote procedure call.
But under the cover, let's see what's going on
when you're using remote procedure call. When the caller
makes its call, it's really is a trap into
the kernel. A caller trap into the kernel. And
what the kernel does is, it validates the call.
And it copies the arguments of the call into
kernel buffers from the client idle space. The kernel
then locates the server procedure that needs to be
executed, copies the arguments that it has buffered
in the kernel buffer into the idle space
of the server. And, once it has done
that, it schedules the server to run the particular
procedure. So that's what's going on in this,
in this direction. At this point, the server
procedure actually starts executing using the arguments of
the call, and performs a function that was requested
by the client. When the server procedure is done
with execution of the procedure. It needs to return
the results of this procedure execution back to the
client. And, in order to do that, it's going to
tap into the kernel, there's the return trap that
the server is experiencing in order to return the
results back to the client. And, what the Kernel
does at this point. Is to copy the results
from the address space of the server into
the kernel buffers and then it copies out the
results from the kernel buffer into the client's address
space and now at this point, we have completed
sending the results back to the client. So the
kernel can then reschedule the client who can then
receive the results. And go on its merry way
of executing whatever it was doing. So that's essentially
what's going on under the cover. So even though the
picture is so clean up here, that a client is making
a call and you get the results and it can continue
with whatever it was doing. In reality, what is going on
under the cover is fairly complex. And more importantly, all of
these actions are happening at runtime as opposed to What I
mentioned about a procedure call, where everything is happening in compile
time, all of these actions are happening at run time, and
that is one of the fundamental sources of performance
hit that an RPC system is going to take in
the fact that everything is being done at the time
of the call. In particular, if you want to analyze all
the overheads that... Or the works that needs to
get done at run time. There are two traps. The
first trap is a call trap. The other trap is
a return trap. There are two traps, and there are
two context switches. So, the first context switch
is when the kernel switches from the client to
the server to the run the server procedure. And
when the server procedure is done with its execution
of the server procedure, it has to reschedule
the client to run again. So, two traps, two
context switches, and one procedure execution. That's the work
that is being done by the runtime system in
order to execute this remote procedure call. So what
are all the sources of overhead now? Well, first of
all, when this call trap happens, the kernel has
to validate the access, whether this client is allowed to
make this procedure call or not the validation has
to happen. And then it has to copy the arguments
from the client's address space into kernel buffers. And
potentially, if you look at this picture, there could multiple
copies that are going to happen in order to
do this exchange between the client and the server,
and then there is the scheduling of the server
in order to run the server code and then there
is the context which overhead, we talked about. The
explicit and implicit costs of doing context switches, there is
a context which overhead that is associated between but,
when we go from the client to the server and
back again to the client from the server,
and of course dispatching a thread on the
processor itself is also time, which is explicit
cost of scheduling. So, before we discuss how
we can reduce the overheads in this remote
procedure call, when the clients and the servers
happen to be on the same machine, let me prime the pump with a, with a quiz.