Remote Invocation: RPC & RMI

Remote Invocation as a Middleware Abstraction exam

In Part III two processes talked through sockets: the programmer opened a connection, turned data into bytes, wrote them, read the answer back and worked out which answer belonged to which question. That works, but every program repeats the same chores, and each chore is a place for bugs. Remote invocation is the idea that removes those chores: the programmer writes something that looks like an ordinary call, and a layer of software underneath turns it into messages.

The value of the abstraction is clearest when you set the two ways of programming side by side. On the left is what you must write yourself with raw sockets; on the right is the same interaction written as a remote call, with the chores moved into middleware.

So remote invocation hides connection management, message boundaries and marshalling. Marshalling is the process of flattening structured data (numbers, strings, objects) into a sequence of bytes that can be sent in a message; unmarshalling rebuilds the data at the other end. Hiding these means less hand-written code and so fewer errors. Remote invocation also matches replies to requests, deals with retransmission and duplicate messages (together these determine the call semantics, explained in 6.5), and finds the server through a binder or registry, a directory that maps names to servers. On top of all that it separates interface from implementation across the network: the client knows only what operations exist, not how they are written.

Three paradigms, each built on the one below

CDK §5.1 describes three ways of doing remote invocation. They are not rivals: each is built on the one below it, going from the lowest level to the highest.

1. Request-reply protocols are a pattern layered on top of plain message passing to support client-server exchanges: the client sends a request, the server sends back a reply. RPC and RMI are both built on them.
2. RPC (Remote Procedure Call) extends the familiar procedure call to procedures that live in other processes, so it belongs with procedural languages such as C.
3. RMI (Remote Method Invocation) extends object method invocation to objects that live in other processes. "RMI" names the general idea; Java RMI is one product that implements it.

Where remote invocation sits

The layer diagram below shows the whole software stack of a distributed system. Remote invocation sits in the middleware, above the basic interprocess communication (IPC) primitives of Part III and below the applications that use it.

Remote invocation is direct communication: the two parties are coupled in both space and time. Coupled in space means the client must know which server it is talking to; coupled in time means the server must be running at the moment the client calls. Indirect communication (Part VII) removes one or both of these couplings by putting an intermediary between them.

The Request-Reply Protocol exam

Every remote call, whatever it looks like to the programmer, ends up as the same little conversation: the client sends a request saying "please run operation X with these arguments", and the server sends back a reply carrying the result. A request-reply protocol is the set of rules for that conversation (CDK §5.2). RPC and RMI rest on it, so it pays to understand it on its own first.

A request-reply exchange is normally synchronous: the client blocks (stops and waits) until the reply arrives. It can also be reliable, because the reply itself acts as an acknowledgement of the request: if a reply comes back, the request must have arrived.

Why build it on UDP rather than TCP? exam

Two transport protocols are available (Part III). TCP is connection-oriented: it sets up a connection first, then delivers a reliable, ordered stream of bytes, sending acknowledgements (messages saying "I got it") and doing flow control (slowing the sender so it cannot swamp the receiver). UDP just sends independent packets called datagrams, with no connection and no guarantee that they arrive. TCP might seem the obvious choice, but it has three overheads that a request-reply exchange does not need:

• Acknowledgements are redundant, because every request is followed by a reply anyway.
• Connection set-up costs two extra pairs of messages before any useful exchange takes place.
• Flow control is redundant for the small arguments and results that most calls pass.

The price of UDP is that the protocol must now cope with lost and duplicated messages itself, which is what 6.3 is about. (There are also good reasons to use TCP after all; they are in 6.4.)

The three primitives

CDK describes the protocol with three operations, one on the client side and two on the server side:

// client side
public byte[] doOperation(RemoteRef s, int operationId, byte[] arguments)
// server side
public byte[] getRequest();
public void sendReply(byte[] reply, InetAddress clientHost, int clientPort);

• doOperation sends a request to the server s, which is identified by its IP address and port. It then blocks in receive until the reply arrives, and returns the reply bytes.
• getRequest acquires a client request via the server's port.
• sendReply sends the reply back to the client at the given host and port.

Notice that doOperation deals only in byte[]: its caller marshals the arguments beforehand and unmarshals the result afterwards. The server, meanwhile, runs a loop: it calls getRequest, selects the operation, executes it and calls sendReply, then goes round again.

The message structure exam

Every request and every reply has the same five fields. Using one layout for both directions keeps the protocol simple.

Two fields need more explanation. The requestId is generated by doOperation and copied into the reply, so that the client can check that a reply belongs to its current request and is not a delayed reply to an earlier one. The operationId can be a plain number (1, 2, 3 …) or, if both sides are written in the same language, a reflective Method object (6.9 shows Java RMI doing exactly this).

Message identifiers

For duplicate detection to work, every message needs an identifier that is unique across the whole system, not just within one client. It is built from two parts:

The requestId wraps round to 0 after 2³²−1. That is safe as long as an identifier's lifetime (how long a message carrying it could still be around) is much shorter than the time it takes to use up the whole sequence.

Failures and Fault-Tolerance Measures exam

Running the protocol over UDP saves messages, but UDP promises nothing: a datagram can vanish. When the client hears nothing back, it faces a hard question: did my request get lost, or did the server run the operation and the reply get lost? This section is about the four measures the protocol uses to live with that uncertainty.

The failure model

A failure model states exactly which failures a design must cope with. For request-reply over UDP it is:

• Omission failures: a message is sent but never delivered (it is lost).
• Out-of-order delivery: messages can arrive in a different order from the one in which they were sent.
• Process crashes: a process can crash, but the model assumes it simply stops and stays stopped. There is no Byzantine (arbitrary) behaviour, where a faulty process sends wrong or malicious messages.

The four measures

1. Timeout (client). When the client's timeout expires, the reply may have been lost after the operation had already run, so giving up at once would be unusual. Instead, doOperation retransmits the request until it either gets a reply or is fairly sure the server has failed, and only then throws an exception.
2. Discard duplicate requests (server). Because the client retransmits, the server may receive the same request twice, for example when it executes more slowly than the client's timeout. It recognises the repeated (client, requestId) and filters out the duplicate. If it has not sent the reply yet, it simply sends it when it has finished.
3. Lost reply. If a duplicate arrives after the reply has already been sent, the server has two options. It can re-execute the operation, which is safe only if the operation is idempotent (defined below), or it can retransmit the stored reply.
4. History. To retransmit replies without re-executing, the server keeps a history: a record of the replies it has sent, as (requestId, reply, client id) entries.

The two steppers below show the measures in action. First the easy case: the request is lost, so the server never saw it, and a retransmission simply gets it through.

The hard case is a lost reply. Now the operation has run, and the retransmitted request is a duplicate. This is the guide's example: a deposit of 10, where running it twice would credit the account twice.

Duplicates do not only come from lost replies. If the server is simply slow, executing for longer than the client's timeout, the client retransmits while the original is still running. Measure 2 covers this case.

Keeping the history small

A history costs memory, and a busy server with many clients could fill up. Two observations keep the cost down. First, each client has only one outstanding request at a time, so the client's next request acknowledges its previous reply, and the server need keep only the last reply per client. Second, clients that exit never send that next request, so the server discards entries after a time limit.

Idempotent operations exam

Idempotence is what makes re-execution (option 3a above) safe: if repeating an operation changes nothing more, the server can just run a duplicate again and needs no history. If all of a server's operations are idempotent, as in Sun NFS (Part VIII), the server needs no history at all.

R, RR and RRA; TCP and HTTP exam

Not every interaction needs the same guarantees. Spector (1982) identified three styles of exchange protocol, which differ in how many messages they send and so in what they can promise. Choosing one is a trade-off between messages sent and certainty gained.

R is for when the client needs neither a result nor a confirmation: it sends its request and continues at once. It runs over UDP with no retries, which is why its semantics are maybe (6.5). RR is used for most client-server exchanges. It needs no separate acknowledgements, because the reply acknowledges the request and the client's next request acknowledges the reply.

RRA adds a third message, an acknowledgement carrying the requestId, whose purpose is to let the server delete history entries as soon as the client has its reply, instead of waiting for a time limit. Acks are cumulative: Ack(n) covers every id up to n, so losing one is harmless. The client sends the ack after the reply has been handed to it, so it is not blocked waiting; but the ack does cost an extra message, so it can instead be piggy-backed on (carried inside) the next request.

Request-reply over TCP

Despite the overheads in 6.2, there are good reasons to run request-reply over TCP:

A tailored UDP protocol is still the better choice when TCP's features are not needed. Sun NFS is the standard example: it moves fixed-size blocks and its operations are idempotent, so it needs no history.

HTTP as a request-reply protocol (brief)

HTTP, the protocol of the Web, is a familiar request-reply protocol. It runs over TCP and specifies the request and reply messages, the methods, and the marshalling: messages are ASCII text, and data carries MIME types (labels saying what kind of data it is), such as text/html. Unlike RPC, where each service defines its own operations, HTTP has a fixed set of methods for all resources. It also offers content negotiation (client and server agree which representation to send) and password-style authentication, where the server issues a challenge and the client responds with credentials. HTTP/1.1 uses persistent connections (one connection reused for many requests); if a connection closes in the middle of a request, the browser resends the request automatically only if it is idempotent.

A safe method changes nothing, so it is idempotent automatically; PUT and DELETE change state but are still idempotent; only POST is neither.

Invocation Semantics exam

After a remote call, the caller wants to know one thing: how many times did the remote procedure actually run? For a local call the answer is always "exactly once". For a remote call it depends on how doOperation and the server deal with lost messages. The guarantee a design gives is called its invocation semantics (or call semantics): what the caller can assume about how many times the procedure was executed.

Three design choices, three semantics

The semantics follow from three choices, all of which you met as fault-tolerance measures in 6.3:

• whether to retry the request, retransmitting it until a reply arrives or the server is presumed dead;
• whether to filter duplicates at the server;
• whether to retransmit results from a history instead of re-executing the procedure.

What each one guarantees

Why not exactly-once?

Exactly-once is the semantics of local calls (barring a process failure). A remote caller cannot achieve it in general, because when the timeout expires it cannot tell a lost request from a lost reply or from a crashed server. The three situations below look identical from the client's side.

Remote Procedure Call (RPC) exam

The request-reply protocol moves bytes; the programmer still has to marshal arguments and pick operation numbers. RPC hides even that. It makes calling a procedure in another process look like calling a procedure in your own program.

Building an RPC system raises three design issues: programming with interfaces, call semantics, and transparency. The subsections take them in turn and then show how RPC is implemented.

Design issue 1: programming with interfaces

A service interface specifies the procedures a server offers and the types of their arguments, without saying how they are implemented. Programming against interfaces brings three benefits:

Distribution also imposes three constraints on what an interface can offer, because client and server are separate processes with separate memories:

1. No access to another process's variables. That is why CORBA "attributes", which look like variables, are really generated getter and setter methods.
2. No call by reference. Instead, each parameter is in (sent in the request), out (returned in the reply), or inout (both).
3. No pointers or addresses, because a memory address is meaningless in another process.

Interface Definition Languages (IDLs). An IDL is a language-neutral notation for interfaces in which every parameter has a type and an in/out direction. It lets programs written in different languages call each other, because a compiler maps the IDL to each language. The alternative is to build RPC into a single language, as Java RMI does. Examples are Sun XDR (used for RPC), CORBA IDL (used for RMI), WSDL (web services) and Protocol Buffers. A CORBA IDL declaration looks like this:

void getPerson(in string name, out Person p);

Design issue 2: call semantics

The second issue is which invocation semantics the RPC system offers: maybe, at-least-once or at-most-once. That is decided by how the communication module implements doOperation (retry or not, filter or not, history or not), exactly as set out in 6.5.

Design issue 3: transparency exam

RPC hides marshalling, message passing and retransmission, aiming at least for location transparency (the caller need not know where the server is) and access transparency (local and remote procedures are called the same way). The question is whether it should go further and make remote calls completely indistinguishable from local ones. There are four reasons why remote calls should not be fully transparent:

Designers have taken different positions. Waldo et al. (1994) argued that the difference belongs in the interface. Argus gave remote calls a different syntax. IDLs can declare exceptions and call semantics.

Implementing RPC exam

An RPC call passes through four kinds of component on its way from client to server and back:

• The client stub procedure, one per procedure, looks like a local procedure to the client. It marshals the procedure id and arguments into a request and unmarshals the results from the reply.
• The communication module, present on both sides, runs the request-reply protocol and implements the call semantics: retransmission, duplicate filtering and reply retransmission.
• The dispatcher uses the procedure id to pick the right server stub.
• The server stub procedure, also one per procedure, unmarshals the arguments, calls the service procedure (the real implementation), and marshals the result into the reply.

The stubs and dispatcher are generated by an interface compiler from the interface definition, and the messages use the layout from 6.2. Step through one call:

Case study: Sun RPC (brief)

Sun RPC was designed for Sun NFS, the network file system of Part VIII. It runs over UDP or TCP (over UDP, messages are limited to about 8–9 KB in practice) and uses at-least-once semantics.

• IDL: its IDL is XDR, which the rpcgen compiler turns into client stubs, a server main containing the dispatcher and server stubs, and XDR marshalling procedures (for C).
• No interface names: instead, every request carries a program number and a version number, and each procedure has a procedure number; procedure 0 is the null "alive?" call. Each procedure takes one input parameter (several values must be packed into a struct) and returns one result.
• Binding: each host runs a port mapper on a well-known port. Servers register (program, version, port) with it, and clients ask the port mapper on the server's host.
• Authentication: every request carries credentials, which may be none, a UNIX uid/gid, a shared key, or Kerberos; the server procedure enforces access control.

RMI and the Distributed Object Model exam

RPC calls procedures. But most modern programs are built from objects: bundles of data with the methods that act on it, referred to by references that can be passed around. RMI brings remote invocation to that world, so that a program's objects can be spread across several processes and still call each other.

RPC vs RMI exam

RPC and RMI share a great deal. Both rely on programming with interfaces, both are built on request-reply, both offer at-least-once or at-most-once semantics, and both use local syntax while exposing distribution in the interface through remote exceptions. The table shows where they differ.

Passing by object reference matters because passing a reference to a large object avoids copying it: the receiver invokes the object remotely instead.

From objects to distributed objects

RMI extends the ordinary local object model, which has five parts:

For distribution, an object's data should be reached only through its methods (encapsulation). A program's state is already split into objects, so distributing those objects is a natural step. Typically servers hold objects and clients invoke them by RMI, and a server object may itself be a client of other servers. Objects may also be replicated, migrated, or copied into a local cache. Because encapsulation is enforced, an object can protect its state against concurrent RMIs using synchronisation, and clients never see the data formats used at each site, which helps with heterogeneity.

Remote and local invocations exam

In the distributed object model, only remote objects can receive remote invocations, while all objects can receive local ones. What makes an invocation remote is crossing a process boundary: an invocation between different processes is remote even when both are on the same computer, and one within a process is local. CDK Fig 5.12 gives the standard example.

The model rests on two fundamental concepts: the remote object reference and the remote interface.

Concept 1: the remote object reference

An ROR must be unique in space and time and must never be reused, so that invoking a deleted object gives an error instead of silently reaching some other object that happens to have inherited its identifier. A typical format (CDK §4.3.4, see Part III) is:

Concept 2: the remote interface

A remote interface specifies which methods of an object can be invoked remotely. Remote processes can call only these methods, whereas local objects can also call the object's other methods. Like any interface, it has no constructors. It is defined either in CORBA IDL, which is multi-language, or in Java by extending Remote.

What else changes

The rest of the local object model carries over, with three changes.

• Actions may now cross processes. RORs are often obtained as results of RMIs: in Fig 5.12, A could get F's reference from B. A new object lives in the process where it was created, and interfaces have no constructors, so "remote instantiation" is done by calling a factory method: an ordinary remote method whose job is to create a new object in the server and return its ROR (the whiteboard's newShape in 6.9 is one).
• Garbage collection needs a distributed garbage collector that cooperates with the local ones, usually by reference counting (6.8). Without GC, remote objects must be deleted explicitly.
• Exceptions. An RMI must be able to raise distribution exceptions, for a crashed or busy server, a lost message or a timeout, as well as the application's own exceptions.

Implementing RMI exam

The model says what RMI looks like to the programmer. This section opens the box: which pieces of software sit between object A and remote object B, what each one does, and how the system knows when a remote object can be thrown away.

The components

The remote reference module and its table

The remote reference module is what lets references travel. The first time a remote object is passed in a message, the module creates an ROR for it and adds a table entry. When an ROR arrives in a message, it looks the reference up and returns the corresponding local proxy or object; if there is none, a new proxy is created and added to the table.

The rest of the machinery

Activation, persistence and location

Keeping every server running all the time just in case someone calls it is wasteful. Activation starts objects on demand, much as inetd starts servers on demand. An object is active if it can be invoked in a running process, and otherwise passive, in which case it consists of its implementation plus its marshalled state. Activation creates an instance from that passive form. Java provides Activatable for this.

A persistent object is one that survives between activations of processes. A persistent object store keeps the marshalled state on disk, activates objects transparently and passivates them again, for example at the end of a transaction. An object counts as persistent either if it is reachable from a persistent root (as in Persistent Java and JDO) or if it inherits from a persistence class (as in Arjuna).

Object location. If objects can migrate between processes, an ROR is no longer an address. A location service then maps RORs to their probable current locations, for example by caching and broadcast (as in Clouds and Emerald), optionally with forward location pointers left behind when an object moves.

Distributed garbage collection exam

In one Java program, the garbage collector frees an object once nothing refers to it. With RMI, references to an object can be held in other processes, which the local collector cannot see. The aim of distributed garbage collection (CDK §5.4.3) is that a remote object survives while any local or remote reference to it exists, and is reclaimed once none does.

Java's algorithm achieves this with reference counting with leases. A lease is permission granted for a limited period only, which must be renewed to continue. The four steps:

1. The server keeps B.holders, the set of client JVMs holding proxies for B. This can simply be an extra column in the remote object table.
2. When client C first receives an ROR for B, it calls addRef(B) and then creates the proxy; the server adds C to B.holders.
3. When C's local GC finds that the proxy is unreachable, C calls removeRef(B) and deletes the proxy; the server removes C from the set.
4. When B.holders is empty and there are no local references either, the server's local GC reclaims B.

Two properties keep the algorithm cheap. Its calls are pairwise request-reply calls between remote reference modules, with at-most-once semantics, so no global synchronisation is needed. And extra calls happen only when proxies are created or deleted, not on every RMI.

Three problems still have to be handled:

• A race. One client's removeRef(B) may arrive before another client's addRef(B) and empty the set too early. The fix: when an ROR is sent while B.holders is empty, the server adds a temporary entry, which stays until the addRef arrives.
• Communication failure. addRef and removeRef are idempotent. If addRef throws an exception, the client creates no proxy and calls removeRef, which is correct whether or not the addRef actually took effect.
• Client crash or a lost removeRef. Handled with leases. The server leases each reference for a limited period, starting at addRef, and stores (client JVM id, lease period). The lease ends either at expiry or at removeRef. Because clients must renew their leases before expiry, a crashed client's entry simply lapses.

Jini leases generalise this idea: a resource is granted for a limited time, instead of running "are you still interested?" protocols. Jini leases are negotiable, whereas Java RMI leases are not.

Case Study: Java RMI exam

Everything so far has been the general model. Java RMI is the real system the exam asks you to program, so this section shows how each idea from 6.7 and 6.8 appears in it (CDK §5.5): which interfaces you extend, how arguments travel, what the registry does, and what really happens during a call.

Key characteristics

Remote interfaces and parameter passing exam

A remote interface extends java.rmi.Remote, and every method declares throws RemoteException; methods may declare application exceptions too. CDK's running example is a shared whiteboard (CDK Fig 5.16), with two remote interfaces:

import java.rmi.*;
import java.util.Vector;

public interface Shape extends Remote {
    int getVersion() throws RemoteException;
    GraphicalObject getAllState() throws RemoteException;    // returns a COPY (Serializable)
}
public interface ShapeList extends Remote {
    Shape newShape(GraphicalObject g) throws RemoteException; // g copied; result is a remote ref
    Vector allShapes() throws RemoteException;                // Vector of Shape remote refs
    int getVersion() throws RemoteException;
}

Reading it line by line: Shape is one shape on the whiteboard, itself a remote object. getVersion returns the version number the shape was created with, and getAllState returns the shape's drawing data as a GraphicalObject, an ordinary serializable class, so the caller receives a copy. ShapeList is the whiteboard as a whole: newShape is a factory method that adds a shape and returns a remote reference to it, allShapes returns a Vector of remote references to every shape, and getVersion returns the whiteboard's current version so clients can tell whether anything new has been drawn.

In Java RMI, arguments are inputs and the result is the single output. Any Serializable object can be passed (a class is serializable if it implements java.io.Serializable, meaning Java knows how to flatten it into bytes); primitives and remote objects count as serializable. How an argument travels depends on its declared type:

To make this work, Java RMI changes ordinary serialization in two ways. First, a Remote object is replaced by its ROR, which includes the name of its class. Second, class descriptions are annotated with a URL from which the class can be downloaded.

Downloading of classes

If the receiver lacks the class of an object passed by value, or of a proxy, the code is downloaded automatically from the URL in the class annotation. This has two advantages: users need not all keep the same set of classes, and new classes, such as a TextObject subclass of GraphicalObject, are used transparently by the server and by other clients.

The catch is that downloaded code is a security risk, so CDK installs an RMISecurityManager; without one, classes are loaded only from the local classpath. Modern Java (not in CDK): RMISecurityManager is deprecated and codebase loading is off by default, so put the shared classes on both classpaths.

RMIregistry, the Java binder exam

A client needs a first ROR before it can call anything; after that, RORs can arrive as results. The RMIregistry provides the first one. An RMIregistry runs on each server computer hosting remote objects. It maps URL-style names to RORs of the objects on that host, while the objects themselves stay in their servers.

The registry is accessed through java.rmi.Naming, using names of the form:

All of these can throw RemoteException. Besides Naming, there is LocateRegistry: LocateRegistry.getRegistry(host, port) returns a Registry, which is itself a remote object with the same methods, and LocateRegistry.createRegistry(port) starts a registry inside the server's own JVM.

Tracing a Java RMI call exam

Here is the complete life of one call, from the server creating its object to the client receiving the result. Step through it slowly; this trace (or the tutors' version of it in 6.12) is a likely "explain how Java RMI works" answer.

The slides describe the same path as an eight-step invocation lifecycle:

1. The client calls the stub (the proxy).
2. The stub serializes the call.
3. The dispatcher deserializes it.
4. The dispatcher calls the method.
5. The method returns.
6. The dispatcher serializes the result.
7. The stub deserializes it.
8. The stub hands the result back to the client.

Design and implementation of Java RMI

Java RMI originally used all the components of 6.8, but two have since been simplified away. Since Java 1.2, reflection (a program's ability to inspect and call its own classes and methods at run time) has provided a generic dispatcher, so skeletons are unnecessary. And before J2SE 5.0, proxies were generated by the rmic compiler from the compiled server class, whereas now they are generated dynamically at run time.

Class hierarchy. The server-side classes form a chain: RemoteObject ← RemoteServer ← {UnicastRemoteObject, Activatable} ← your servant class. At the top, RemoteObject holds the ROR and provides equals (which compares RORs), toString, and readObject/writeObject.

Build a Java RMI Program, Mark by Mark 10-mark question

The exam's one 10-mark question asks you to write a complete Java RMI client and server, by hand, from memory. The 2026 practice exam's version (Q11) prints its marking rubric, and this section builds a complete program in the order that rubric rewards, so that every piece you write visibly earns a mark. The example is the guide's Hello program (§6.5.4); at the end you apply the same skeleton to the practice exam's dictionary service.

Step 1 · The remote interface 2 marks

Start with the contract both programs share. It lists the methods clients may call remotely.

Hello.java · needed by BOTH client and server

// Hello.java -- remote interface, needed by BOTH client and server
import java.rmi.Remote;
import java.rmi.RemoteException;

public interface Hello extends Remote {                    // marks it as a remote interface
    String sayHello(String name) throws RemoteException;   // every remote method throws RemoteException
}

• extends Remote: java.rmi.Remote is a marker interface with no methods; extending it is what tells Java RMI that Hello's methods may be invoked from another JVM.
• throws RemoteException on every method: any remote call can fail in transit, and Java forces the caller to deal with that. This is "remoteness expressed in the interface" from 6.6.
• Argument and result types must be serializable or remote: String is serializable, so it is passed by value.

Step 2 · The servant 3 marks

Next, the class that really does the work: the servant, the object that lives in the server and implements the interface.

HelloImpl.java · server only

// HelloImpl.java -- servant
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;

public class HelloImpl extends UnicastRemoteObject implements Hello {
    private int calls = 0;                                 // shared state

    public HelloImpl() throws RemoteException {
        super();                                           // exports the object on an anonymous port
    }

    @Override
    public synchronized String sayHello(String name) {     // RMI threads may call concurrently
        calls++;
        return "Hello, " + name + " (call " + calls + ")";
    }
}

• extends UnicastRemoteObject: inherits the remote-object machinery (see the class hierarchy in 6.9). implements Hello: promises to provide every method of the remote interface.
• The constructor calls super(), which exports the object on an anonymous port so it can receive remote calls. Exporting can fail, so the constructor must declare throws RemoteException.
• synchronized: the RMI runtime may run calls from different clients on different threads at the same time (Part IV), and calls++ is a read-modify-write on shared state, so it must be protected.
• The implementation of sayHello may leave out throws RemoteException, because the method body itself throws nothing remote; the interface keeps it for callers.

Step 3 · The server: create, export, bind 1 mark

HelloServer.java · server only

// HelloServer.java
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class HelloServer {
    public static void main(String[] args) {
        try {
            Registry registry = LocateRegistry.createRegistry(1099); // registry inside this JVM
            Hello obj = new HelloImpl();                             // create and export the servant
            registry.rebind("HelloService", obj);                    // name -> remote reference
            System.out.println("Server ready");  // the JVM stays alive: RMI listener threads keep running
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

• createRegistry(1099) starts a registry inside the server's own JVM on the default port, so no separate registry process is needed.
• new HelloImpl() creates and exports the servant (the constructor in step 2 did the exporting). The variable is typed as the interface Hello.
• rebind("HelloService", obj) is the line that earns the binding mark: it maps the name to the servant's remote reference, replacing any old binding.
• main then ends, but the program keeps running: the RMI runtime's listener threads keep the JVM alive, waiting for calls.

Step 4 · The client: look up and invoke 2 marks

HelloClient.java · client only

// HelloClient.java
import java.rmi.NotBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class HelloClient {
    public static void main(String[] args) {
        String host = (args.length > 0) ? args[0] : "localhost";
        try {
            Registry registry = LocateRegistry.getRegistry(host, 1099); // proxy for the remote registry
            Hello stub = (Hello) registry.lookup("HelloService");       // proxy implementing Hello
            System.out.println(stub.sayHello("Alice"));                 // looks local, is an RMI
        } catch (RemoteException e) {            // communication or server failure
            System.err.println("Remote failure: " + e.getMessage());
        } catch (NotBoundException e) {          // name not registered
            System.err.println("Not bound: " + e.getMessage());
        }
    }
}

• getRegistry(host, 1099) returns a proxy for the remote registry on the server's host.
• lookup("HelloService") returns the remote reference as a Remote, deserialized as a proxy; the cast (Hello) gives it the interface type. The name must match the server's rebind exactly.
• stub.sayHello("Alice") looks like a local call but is a full remote invocation (6.9). Run against the server above, the first call prints Hello, Alice (call 1).

Step 5 · Two distinct kinds of exception 2 marks

The rubric wants two distinct kinds of error handled, so make each catch handle a different kind of failure and say so in a comment. The client above already does: RemoteException is a communication failure and NotBoundException is a naming failure. An application exception declared in the interface would be a third kind.

Compile and run

Since J2SE 5.0 there is no rmic step: proxies are generated at run time. Compile everything and start the server before the client:

javac *.java
java HelloServer                 # terminal 1: prints "Server ready" and keeps running
java HelloClient localhost       # terminal 2: prints "Hello, Alice (call 1)"

Variations worth knowing

Naming.rebind("//localhost:1099/HelloService", obj);                 // server
Hello stub = (Hello) Naming.lookup("rmi://host/HelloService");       // client

ShapeList stub = (ShapeList) UnicastRemoteObject.exportObject(servant, 0);  // 0 = anonymous port

public interface Counter {
    int next();
}
public class CounterImpl implements Counter {
    private int n = 0;
    public int next() { return ++n; }
}
// server: registry.rebind("Counter", new CounterImpl());
// client: Counter c = (Counter) registry.lookup("counter");

// DictionaryService.java -- remote interface, needed by BOTH sides   [interfaces: 2 marks]
import java.rmi.Remote;
import java.rmi.RemoteException;

public interface DictionaryService extends Remote {
    boolean add(String word, String meaning) throws RemoteException;   // ADD: false if present
    String search(String word)                                         // SEARCH: the meaning
            throws RemoteException, WordNotFoundException;
    boolean delete(String word) throws RemoteException;                // DELETE: false if absent
}

// WordNotFoundException.java -- application exception, sent back to the client by RMI
public class WordNotFoundException extends Exception {   // Exception is Serializable
    public WordNotFoundException(String word) {
        super("No such word: " + word);
    }
}

// DictionaryServant.java -- implements the remote interface   [implementation: 3 marks]
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
import java.util.concurrent.ConcurrentHashMap;

public class DictionaryServant extends UnicastRemoteObject implements DictionaryService {
    // RMI may run calls from different clients on different threads: use a thread-safe map
    private final ConcurrentHashMap<String, String> words = new ConcurrentHashMap<>();

    public DictionaryServant() throws RemoteException {
        super();                                   // exports the object to receive remote calls
    }

    @Override
    public boolean add(String word, String meaning) {
        return words.putIfAbsent(word.toLowerCase(), meaning) == null;  // atomic check-then-add
    }

    @Override
    public String search(String word) throws WordNotFoundException {
        String meaning = words.get(word.toLowerCase());
        if (meaning == null) throw new WordNotFoundException(word);      // re-thrown at client
        return meaning;
    }

    @Override
    public boolean delete(String word) {
        return words.remove(word.toLowerCase()) != null;
    }
}

// DictionaryServer.java -- creates the servant and binds it   [binding: 1 mark]
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class DictionaryServer {
    public static void main(String[] args) {
        try {
            Registry registry = LocateRegistry.createRegistry(1099);  // registry in this JVM
            DictionaryService dict = new DictionaryServant();         // create and export
            registry.rebind("Dictionary", dict);                      // name -> remote ref
            System.out.println("Dictionary server ready");
        } catch (RemoteException e) {            // e.g. port 1099 in use, export failed
            System.err.println("Server failed to start: " + e.getMessage());
        }
    }
}

// DictionaryClient.java   [lookup and invocation: 2 marks; errors and exceptions: 2 marks]
import java.rmi.NotBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class DictionaryClient {
    public static void main(String[] args) {
        String host = (args.length > 0) ? args[0] : "localhost";
        try {
            Registry registry = LocateRegistry.getRegistry(host, 1099);
            DictionaryService dict =
                    (DictionaryService) registry.lookup("Dictionary");  // returns a stub
            System.out.println(dict.add("socket", "an endpoint of a two-way link")
                               ? "Added" : "Already in the dictionary");
            System.out.println("socket: " + dict.search("socket"));
            System.out.println(dict.delete("socket") ? "Deleted" : "Not in the dictionary");
            System.out.println("socket: " + dict.search("socket"));  // throws: word gone
        } catch (WordNotFoundException e) {  // application error: no such word
            System.err.println(e.getMessage());
        } catch (NotBoundException e) {      // naming error: nothing bound as "Dictionary"
            System.err.println("Service not registered: " + e.getMessage());
        } catch (RemoteException e) {        // communication failure: server or registry down
            System.err.println("Remote failure: " + e.getMessage());
        }
    }
}

Callbacks: The Shared Whiteboard exam

RMI as described so far is one-way: clients call servers. But often a client wants to know when something changes on the server, for example when another user draws on a shared whiteboard. The whiteboard example shows the two ways to find out: polling (keep asking) and callbacks (be told).

The application

Users share a drawing surface. The server stores every shape with a version number, incremented for each new shape, so clients can fetch only the shapes they lack. On the server, ShapeListServant implements ShapeList, keeping the shapes in a Vector. Its newShape(g) is a factory method: it increments the version, creates a ShapeServant(g, version) remote object, stores it, and returns its reference. The server's main creates the servant, exports it and rebinds it.

A polling client works in four steps:

1. It calls lookup to get the ShapeList.
2. It calls allShapes(), then getAllState() on each shape to display it.
3. It calls newShape(g) when the user draws.
4. It periodically calls getVersion() to detect shapes added by other users.

With callbacks, instead of clients polling, the server notifies the clients when the event occurs. In RMI this takes three steps:

1. The client creates a callback object, a remote object with a method the server can call. The client thereby also becomes an RMI server.
2. The server offers a register method, through which clients give it the RORs of their callback objects, and it keeps a list of them.
3. When the event happens (here, a new shape), the server invokes every registered callback.

The callback code (CDK's version, corrected):

import java.rmi.Remote;
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;

public interface WhiteboardCallback extends Remote {   // CDK prints "implements Remote", a typo
    void callback(int version) throws RemoteException;
}
// Added to ShapeList:  int register(WhiteboardCallback cb) throws RemoteException;  // returns callbackId
//                      void deregister(int callbackId) throws RemoteException;

class WhiteboardCallbackImpl extends UnicastRemoteObject implements WhiteboardCallback {
    WhiteboardCallbackImpl() throws RemoteException { super(); }  // exported: client acts as a server
    public void callback(int version) {                          // runs on an RMI thread in the client
        System.out.println("New shapes up to version " + version);
    }
}
// Client: int id = shapeList.register(new WhiteboardCallbackImpl()); ... shapeList.deregister(id);
// Server: on each new shape, call cb.callback(version) for every registered cb;
//         on RemoteException, remove that client from the list.

• WhiteboardCallback is an ordinary remote interface, so it must extend Remote (CDK's "implements" is a typo: an interface cannot implement another).
• WhiteboardCallbackImpl is a servant that lives in the client. Its constructor exports it, which is exactly what turns the client into an RMI server.
• register passes the callback object to the server. Its declared type is a remote interface, so it travels by reference: the server receives a proxy it can call back on.
• callback runs on an RMI runtime thread inside the client, not on the client's main thread.
• On the server, a RemoteException from a callback means that client has gone, so it is removed from the list.

Polling has two drawbacks: constant polling degrades server performance, and clients cannot update users promptly. Callbacks bring two problems of their own. First, the server's callback list goes stale when clients exit without deregistering; the fix is leases. Second, the server makes a series of synchronous RMIs, one after another, so a slow client delays the rest; the fixes are threads, asynchronous calls (CORBA oneway) or indirect communication (Part VII).

Pitfalls and Tutorial Answers

This last section collects the mistakes that most often cost marks on this topic, and the official tutorial answers for Weeks 7 and 8.

Tutorial 6 part 2 and Tutorial 7 official answers

These answers come from the tutors' official solutions on Ed: Tutorial 06 (Week 7, on remote invocation) and Tutorial 07 (Week 8, which repeats the Java RMI question). Staff have confirmed that tutorial content is examinable. Part 1 of Tutorial 06 (operating systems) is in Part V.

Code demos (Weeks 7–8). The tutorials also demonstrated an RMI client and server, and sending or receiving a file over sockets; 6.10 covers the RMI program.

Final check