Because Quicksilver is a distributed operating system,
IPC both within, and on the local data
network is a crucial component of Quicksilver. And
this picture shows the semantics of the IPC
call. In the kernel, there is a
data structure called service queue. Which is created
by the server that wants the service, request
from clients. And clients make a request, and
the kernel does an upcall to the server to
indicate that this is a client's request. The server
executes the upcall associated with this particular request. When
it completes the request, the completion, goes back into
the service queue. And that is an indication for
the kernel, to give a response back to the
client. So then the synchronous client call where the
client is waiting, til the request is actually serviced,
and the completion response comes back to
the client. And the service queue, is a
global service queue, just like UNIX socket.
So any process, anywhere in the network, which
has knowledge about the service queue, can
connect to it and make requests on the
service queue. And so nearly any server process
in the entire distributed system can service requests
that are coming into the service queue. And
there are some fundamental guarantees provided by Quicksilver
for interprocess communication which includes no loss, or
duplication of requests. So the request comes in,
it will get done exactly once. And it
also ensures that there's no duplication. It also
ensures that there is no loss of the
request. And Quicksilver also takes care of the liability
of the data transfer that is inherent when the client and the server, are
on remote machines. And because the service
queue data structure is globally unique for every
such service. There is location transparency, for
client server interactions. Or in other words
a client does not needs to know, where in the network its particular request is
being serviced. For that is yet another feature of the IPC
guarantee. Or the IPC call can also be asynchronous. What that means is,
the client can make a request asynchronously. And continue with its
own execution, whatever it wants to do, it
doesn't have a block on this. The kernel is
going to take the same action, and that is, if
there is a server that is available, then the
kernel is going to pass it to that server to execute
that request. And, when the completion comes back in, it is
buffered in the service queue by the kernel, waiting for
the client to come back, and ask for the response. So
the client, at some point, has to do a wait
on the service queue to indicate that I'm ready to receive
the response that may have come, back for the request
that I made earlier. And when the client does the wait,
if the original request has already been serviced by
the server, and the response is sitting in the service
queue, then the kernel, will deliver the response to
the client. If not, the client will wait until the
response comes back. So this is the asynchronous client
call, but in either case, as I mentioned earlier. The
IPC guarantees hold that there is no loss of
the request, and there is no duplication of the request.
As you can see from the semantics
that I described just now, that Quicksilver IPC
is very similar to remote procedure call.
In fact, the remote procedure call paradigm was
invented around the same time as the
Quicksilver Operating System. And since all services are
contained in several processes, IPC is fundamental
to Quicksilver. The IPC semantic supported by Quicksilver
allows, multiple servers to wait on a service queue.
And the way they will do that is by making
a call called offer which is essentially saying, I'm willing
to offer my services for this particular service queue. Any
number of servers can make this offer and that
essentially means that if a request comes in, thatany one
of these servers can be called by the kernel depending
on the busyness of the servers with respect to handling
requests that have come in for the service queue
in the past. The client server relationship is interchangeable. For
example, a client can make a call on a
file system server and the file system server in turn
makes a call. To a directory server and a
call to a data server. So, in this case, the
file system becomes the client to the directory server
and the data server. So in that sense, the client
server relationship is interchangeable. Now the only
reason for me to spend some time
describing the IPC semantics of Quicksilver. Is
because the recovery mechanism is tied intimately with
the IPC. And in fact, that's how you can have the cake and eat it too in
Quicksilver. In other words, the client server interactions have to use IPC. So
the recovery mechanism, using transactions, rides
on top of the IPC, essentially bundling
the recovery mechanism with ICP to
get it cheaply. Another interesting footnote I
wanted to mention. The Quicksilver system was first conceived in the early 80s,
but the first paper that described it appeared in 1988. And this is certainly
the difference between academic research and industrial research
at least in the olden days. Academic research,
we tend to shout often. I'm an academic myself, so I take part of the blame.
At least in the olden days, industrial research
used to take the approach of publishing, a
paper, especially in systems designed, when it is
fully cooked. Like I said, Quicksilver was designed and
implemented in the early 80s, 1984 to 88, but the
first paper came out in 1988. But nowadays I have to
mention that everyone is shouting often, which explains the proliferation
of conferences that you see around the country and the world.