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.