RPC Communication and Other issues
Issues that must be addressed:
- Parameters must be marshalled into a standard representation.Parameters consist of simple types (e.g., integers) and compound types (e.g., C structures or Pascal records). Moreover, because each type has its own representation, the types of the various parameters must be known to the modules that actually do the conversion. For example, 4 bytes of characters would be uninterpreted, while a 4-byte integer may need to the order of its bytes reversed.
- Call-by-reference not possible: the client and server don’t share an address space. That is, addresses referenced by the server correspond to data residing in the client’s address space.One approach is to simulate call-by-reference using copy-restore. In copy-restore, call-by-reference parameters are handled by sending a copy of the referenced data structure to the server, and on return replacing the client’s copy with that modified by the server.
However, copy-restore doesn’t work in all cases. For instance, if the same argument is passed twice, two copies will be made, and references through one parameter only changes one of the copies.
- How does the client know who to call, and where the service resides?The most flexible solution is to use dynamic binding and find the server at run time when the RPC is first made. The first time the client stub is invoked, it contacts a name server to determine the transport address at which the server resides.
- Transport protocol:
- What transport protocol should be used?
- Exception handling:
- How are errors handled?
We’ll examine one solution to the above issues by considering the approach taken by Birrell and Nelson . Binding consists of two parts:
- refers to what service the client wants to use.In B&N, remote procedures are named through interfaces. An interface uniquely identifies a particular service, describing the types and numbers of its arguments. It is similar in purpose to a type definition in programming languauges.
For example, a “phone” service interface might specify a single string argument that returns a character string phone number.
- refers to finding the transport address at which the server actually resides. Once we have the transport address of the service, we can send messages directly to the server.
In B&N’s system, a server having a service to offer exports an interface for it. Exporting an interface registers it with the system so that clients can use it.
A client must import an (exported) interface before communication can begin. The export and import operations are analogous to those found in object-oriented systems.
Interface names consists of two parts:
- A unique type specifies the interface (service) provided. Type is a high-level specification, such as “mail” or “file access”.
- An instance specifies a particular server offering a type (e.g., “file access on wpi”).
B&N’s RPC system was developed as part of a distributed system called Grapevine. Grapevine was developed at Xerox by the same research group the developed the Ethernet.
Among other things, Grapevine provides a distributed, replicated database, implemented by servers residing at various locations around the internet.
Clients can query, add new entries or modify existing entries in the database.
The Grapevine database maps character string keys to entries called RNames. There are two types of entries:
- A single instance of a service. Each server registers the transport address at which its service can be accessed and every instance of an interface is registered as an individual entry. Individual entries map instances to their corresponding transport addresses.
- The type of an interface, which consists of a list of individual RNames. Group entries contain RNames that point to servers providing the service having that group name. Group entries map a type (interface) to a set of individual entries providing that service.
For example, if wpi and bigboote both offered file access, the group entry “file access” would consists of two individual RNames, one for wpi and bigboote‘s servers.
Semantics of RPC
Unlike normal procedure calls, many things can go wrong with RPC. Normally, a client will send a request, the server will execute the request and then return a response to the client. What are appropriate semantics for server or network failures? Possibilities:
- Just hang forever waiting for the reply that will never come. This models regular procedure call. If a normal procedure goes into an infinite loop, the caller never finds out. Of course, few users will like such semantics.
- Time out and raise an exception or report failure to the client. Of course, finding an appropriate timer value is difficult. If the remote procedure takes a long time to execute, a timer might time-out too quickly.
- Time out and retransmit the request.
While the last possibility seems the most reasonable, it may lead to problems. Suppose that:
- The client transmits a request, the server executes it, but then crashes before sending a response. If we don’t get a response, is there any way of knowing whether the server acted on the request?
- The server restarts, and the client retransmits the request. What happens? Now, the server will reject the retransmission because the supplied unique identifier no longer matches that in the server’s export table. At this point, the client can decide to rebind to a new server and retry, or it can give up.
- Suppose the client rebinds to the another server, retransmits the request, and gets a response. How many times will the request have been executed? At least once, and possibly twice. We have no way of knowing.
Operations that can safely be executed twice are called idempotent. For example, fetching the current time and date, or retrieving a particular page of a file.
Is deducting $10,000 from an account idempotent? No. One can only deduct the money once. Likewise, deleting a file is not idempotent. If the delete request is executed twice, the first attempt will be successful, while the second attempt produces a “nonexistent file” error.
While implementing RPC, B&N determined that the semantics of RPCs could be categorized in various ways:
- Exactly once:
- The most desirable kind of semantics, where every call is carried out exactly once, no more and no less. Unfortunately, such semantics cannot be achieved at low cost; if the client transmits a request, and the server crashes, the client has no way of knowing whether the server had received and processed the request before crashing.
- At most once:
- When control returns to the caller, the operation will have been executed no more than once. What happens if the server crashes? If the server crashes, the client will be notified of the error, but will have no way of knowing whether or not the operation was performed.
- At least once:
- The client just keeps retransmitting the request until it gets the desired response. On return to the caller, the operation will have be performed at least one time, but possibly multiple times.