Making RPC Cheap (Actual Calls) cont – Georgia Tech – Advanced Operating Systems


Recall that we had four copies in doing the client call, just transferring the arguments from the client to the server’s domain. That was the original cost. And the four copies were first creating an RPC packet, copying that RP-, RPC packet into the kernel buffer. Copying the kernel buffer out into the server domain. And in the server domain, the server stub getting into action. Taking this information that had been passed up to it by the kernel, and putting it on the server stack to start executing the server code. So this was the original costs that we incurred in terms of copying. Now, life is much simpler. All that is happening is on the client side, the client’s stub is copying the parameters into the A-stack. And I want to emphasize the word copying the parameters. That is very different from what was happening over here. Here the client stub was doing a lot more work. It actually had to serialize the data structures that are being passed as, as actually arguments into a sequence of bytes in this RPC message. Whereas here, it is simply copying it, because the client and the server know exactly what the semantics and syntax of the arguments that are being passed back and forth and therefore there is no need to serialize the data structure. It just has to create a copy of the parameters into the A-stack. And this A-stack is, of course, shared between the client and the server. So what the server stub is going to do is basically going to take the arguments that are now sitting in the A-stack and copy it into the E- stack. Remember, the execution stack provided by the kernel for executing the server procedure? That is a, the special server stack that we’re going to use. So the arguments are copied by the server stub into the E-stack, and once it is done the server procedure is now ready to be executed in the server domain. So what we accomplished is that the entire client server interaction requires only two copies. One for copying the arguments from the client stack into the A-stack, which is usually called the marshal link of the arguments. And the second copy is taking the A-stack arguments that are sitting in the A-stack and copying it into the server’s stack, that is the unmarshal link. So, these are the two copies involved. One on the client side and one on the server side, and both these copies are happening above the kernel. It’s in the user space, right? It is in the space of the client that the client stub is making this copy of the arguments into the A-stack. And similarly, it is in the space of the server domain that the unmarshaling is happening. And, of course, this is the work done. So we’re basically taking the original four copies and gotten rid of the two copies that were being done inside the kernel. One into the kernel and one out of the kernel. These two copies, which is done by the kernel, we got rid of them. And instead, we have only two copies. These copies, even though you’re calling it copies, it is, it is really not as tedious as creating an RPC message. It is, it is a more efficient way of creating the information that needs to be passed back and forth between the client and the server using this A-stack. And needless to say, the same thing is going to happen in the reverse direction for returning the results. So it is just that, it is, the server stack that is going to have the result and the server stub is going to put it in the A-stack and the client stub is going to take it from the A-stack and give it to the client so that the client can state resuming its execution. So there’s two copies involved in going from the client to the server, and two copies involved in going back to the client from the server.

, , , , , , ,

Post navigation

Leave a Reply

Your email address will not be published. Required fields are marked *