Remote Procedure Calls (RPC) are a popular model for building client/server applications.RPC falls somewhere between the transport layer and application layer in the OSI model.
Parameter Passing in RPC:
- Functions in an application that runs in a single process may collaborate via parameters and/or global variables
- Functions in an application that runs in multiple processes on the same host may collaborate via message passing and/or nondistributed shared memory
- However, passing parameters is typically the only way that RPC-based clients and servers share information.
- Parameters that are passed by value are fairly simple to handle
- The client stub copies the value from the client
and packages into a network message
- Consider a remote procedure, sum(i, j), which takes two integer parameters and returns their arithmetic sum.
The client stub takes its two parameters and puts them in a message and also puts the name or number of the procedure to be called in the message.
- When the message arrives at the server, the stub examines the message to see which procedure is needed, and then makes the appropriate call.
- When the server has finished execution, it takes the result provided by the server and packs it into a message. This message is sent back to the client stub, which unpacks it and returns the value to the client procedure
- Parameters passed by reference are much harder:
- For example distributed systems with distributed shared-memory mechanisms can allow passing of parameters by reference.
- A pointer is meaningful only within the address space of the process in which it is being used.
Suppose there are two parameters to be passed, if the second parameter is the address of the buffer which is 1000 on the client, one cannot just pass the number 1000 to the server and expect it to work. Address 1000 on the server might be in the middle of the program text.
- e.g., in C when the address of a variable is passed
e.g., passing arrays
- Or more generally, handling pointer-based data structures
e.g., pointers, lists, trees, stacks, graphs, etc
Typical solutions include:
- Have the RPC protocol only allow the client to pass arguments by value
However, this reduces transparency even further.
- Use a presentation data format where the user specically denes what the input arguments are and what the return values are.e.g., Sun's XDR routines
- RPC facilities typically provide an \interface definition language" to handle this
. e.g., CORBA or DCE IDL.