Week 13 - Remote Procedure Calls
Additional reading
Remote procedure calls (RPC)
Remote procedure calls (PRC)
Link to originalRemote procedure calls (PRC)
A Remote Procedure Call (RPC) is a protocol that allows a program to execute a procedure (function) on a different address space, typically on another computer over a network, as if it were a local function call. This offers
- Transparency: The programmer calls a function like normal, but behind the scenes, that call is sent to another machine or process.
- Abstraction: The network communication, serialization, and deserialization are abstracted away from the programmer.
- Bidirectional: RPC can be synchronous (waiting for a response) or asynchronous (fire-and-forget).
- Client-server model: The caller is the client, and the callee (who implements the procedure) is the server.
To achieve this RPC has some requirements:
- Offers a client and server interface.
- Implements a procedure call Interface.
- When RPC was invented procedural languages where big, this is synchronous and when it is called remote procedure call.
- Type checking.
- This offers error handling, and
- packet bytes interpretation.
- Cross-machine conversations.
- Higher-level protocol.
- Access control, fault tolerance, and
- Can support different transport protocols.
Below is an example flow of an RPC call:
Steps to carry out an RPC operation
- Register: (Optional) The server registers what procedures it offers, the argument types and location.
- Bind: Client binds to the connecting server (this bind can get reused for multiple connections).
- Call: Client makes RPC call and control passes to the client stub.
- Marshal: The client stub serialises all the arguments into a message.
- Send: The client stub sends the message to the server.
- Receive: Server receives the message, passes the message into the server stub.
- Unmarshal: Server stub deserialises the message.
- Actual call: The server stub hands the parameters to the local implementation to carry out the implementation.
- Result: The local implementation hands the result back to the server stub.
- Similar operations to 4-7 happen to send the result back to the client.
Interface definition language
The goal of RPC is that the server and client do not need to be programmed together or even written in the same language. To achieve this we need some language agnostic way to define the methods that can be called and the messages that are needed by them. This is where an Interface definition language (IDL) comes in.
Interface definition language (IDL)
Link to originalInterface definition language (IDL)
An Interface Definition Language (IDL) is a formal language used to define the interface between software components, especially in Remote Procedure Calls (RPC) systems. It describes function names, parameters, return types, and data structures in a way that is independent of programming language.
An important aspect to any IDL is it includes a version number. This allows for easy upgrades to any interface you have defined.
Marshalling
Marshalling is the process of taking input parameters that could be anywhere within a processes address space and putting them into a message to be sent to the other party. This will include some standards on how to serialize different types such as arrays and integers.
Unmarshalling is the opposite procedure when the other party receives the message.
Both these will not need to be written by the developer - instead they will be built into how the RPC framework is built.
What about pointers?
RPC frameworks have two choices when a pointer is passed in:
- Don’t support it and throw an error, or
- Serialize the object the pointer is pointing at.
Binding and Registry
For the server and client to connect the client needs to know the servers address and port that it is operating on. Also the client should know what functions the server offer and the expected inputs/outputs of these functions. After this is known the client can ‘bind’ to the server to make the calls.
Knowing where the server is and what functions it offers can either be done explicitly in a hard coded fashion or there can be a registry that lets potential clients know what machines and functions are out there.
The registry can either be hosted centrally or placed on each machine. This will offer a central way to get the servers that support some function name and a version of the protocol.
Handling failure
RPC frameworks implement error handling however, due to the framework operating over a network it sometimes can not know the cause of the issue. Therefore it offers a best guess at issues within this framework.
SunRPC
This is an RPC framework developed by Sun in the 80s (bought by Oracle) for unix. They made the following design choices:
- Hosts a registry on each machine,
- It uses the XDR IDL.
- This uses a rpcgen compiler to convert .x (XDR) files into language specific implementations.
- Pointers are allowed and serialized.
- It makes a best effort attempt to catch information about failures and has built in retries.
Java RMI
This is an RPC framework also developed by Sun but specifically for the Java language.
As this is specific to Java, it uses that for its IDL the framework matches Java’s OOP semantics. The implementation is split into two layers: