Chapter 5

Remote invocation

Reference Book:
From Coulouris, Dollimore, Kindberg and Blair
Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
Contents

 Introduction

 Request-reply protocols

 Remote procedure call

 Remote method invocation

 Case study: Java RMI

 Summary

2
  This chapter has discussed three paradigms for distributed programming: request-reply
protocols, remote procedure calls and remote method invocation.

Figure 5.1 Middleware layers

Applications, Services
This chapter
(and Chapter 6) Remote invocation, indirect communication
Middleware
Underlying interprocess communication primitives: layers
Sockets, message passing, multicast support, overlay networks

UDP and TCP

Introduction
 Request-Reply Protocols: represent a pattern on top of message passing and
support the two-way exchange of messages as encountered in client-server
computing.

• Protocols provide relatively low-level support for requesting the execution of a

remote operation, and also provide direct support for RPC and RMI.

 Remote Procedure Call: which allows client programs to call procedures

transparently in server programs running in separate processes and generally in
different computers from the client.

 Remote Method Invocation: is an extension of local method invocation that

allows an object living in one process to invoke the methods of an object living in
another process.

4
Request-Reply Protocol
 Request-Reply Communication: is synchronous because the client process blocks
until the reply arrives from the server. It can also be reliable because the reply from
the server is effectively an acknowledgement to the client.

• Asynchronous request-reply communication is an alternative that may be

useful in situations where clients can afford to retrieve replies later.

• The client-server exchanges are described the send and receive operations in the Java
API for UDP datagrams, although many current implementations use TCP streams.

5
Request-Reply Protocol (Cont’d)

 A protocol built over datagrams avoids unnecessary overheads associated with the
TCP stream protocol.
• Acknowledgements are redundant, since requests are followed by replies.
• Establishing a connection involves two extra pairs of messages in addition to the pair
required for a request and a reply.
• Flow control is redundant for the majority of invocations, which pass only small
arguments and results.

6
Request-Reply Protocol (Cont’d)

Figure 5.2 Request-reply communication

Client Server

Request
doOperation
message getRequest
select object
(wait) execute
Reply method
message sendReply
(continuation)
Request-Reply Protocol (Cont’d)
 doOperation method: is used by clients to invoke remote operations.
• The client calling doOperation marshals the arguments into an array of bytes and
unmarshals the results from the array of bytes that is returned.

 getRequest: is used by a server process to acquire service requests.

 When the server has invoked the specified operation, it then uses sendReply
to send the reply message to the client.
• When the reply message is received by the client the original doOperation is
unblocked and execution of the client program continues.

8
Request-Reply Protocol (Cont’d)

Figure 5.3 Operations of the request-reply protocol

public byte[] doOperation (RemoteRef s, int operationId, byte[] arguments)

sends a request message to the remote server and returns the reply.
The arguments specify the remote server, the operation to be invoked and the
arguments of that operation.

public byte[] getRequest ();

acquires a client request via the server port.

public void sendReply (byte[] reply, InetAddress clientHost, int clientPort);

sends the reply message reply to the client at its Internet address and port.
Request-Reply Protocol (Cont’d)

Figure 5.4 Request-reply message structure

messageType int (0=Request, 1= Reply)

requestId int

remoteReference RemoteRef
operationId int or Operation
arguments array of bytes
Request-Reply Protocol (Cont’d)
 Message identifier: consists of two parts:
1. a requestId, which is taken from an increasing sequence of integers by the
sending process;
2. an identifier for the sender process, for example, its port and Internet address.

 Failure Model of the Request-Reply Protocol : If the three primitives

doOperation, getRequest and sendReply are implemented over UDP datagrams,
then they suffer from the same communication failures.
• They suffer from omission failures.
• Messages are not guaranteed to be delivered in sender order.

11
 Failure Model of the Request-Reply Protocol (Cont’d)
 Timeouts: may have been due to the request or reply message getting lost
• doOperation sends the request message repeatedly until either it gets a reply or it is
reasonably sure that the delay is due to lack of response from the server rather than to
lost messages.

 Discarding duplicate request messages: When the request message is retransmitted,

the server may receive it more than once. The protocol is designed to recognize
successive messages with the same request identifier and to filter out duplicates.

 Lost reply messages: If the server has already sent the reply when it receives a
duplicate request it will need to execute the operation again to obtain the result,
unless it has stored the result of the original execution. Some servers can execute their
operations more than once and obtain the same results each time.

• An idempotent operation is an operation that can be performed repeatedly with the

same effect as if it had been performed exactly once.

 History: For servers that require retransmission of replies without re-execution of

operations, a history may be used. 12
 Request-Reply Protocol (Cont’d)
 Styles of exchange protocols
1. the request (R) protocol: Single Request message is sent by the client to the server.
The client requires no confirmation that the operation has been executed.
2. the request-reply (RR) protocol: It is useful for most client-server exchanges
because it is based on the request-reply protocol. Special acknowledgement messages
are not required.
3. the request-reply-acknowledge reply (RRA) protocol: It is based on the exchange of
three messages: The Acknowledge reply message contains the requestId from the reply
message being acknowledged.

13
Request-Reply Protocol (Cont’d)

 Use of TCP streams to implement the request-reply protocol

 If the TCP protocol is used,

• Allowing arguments and results of any size to be transmitted.

• Request and reply messages are delivered reliably.

• No need for the request-reply protocol to deal with retransmission of messages and
filtering of duplicates or with histories.

14
Reading Assignment
 HTTP: An example of a request-reply protocol

1. Web servers manage resources implemented in different ways:

2. Protocol allows for content negotiation and password-style authentication:

3. HTTP is implemented over TCP.

4. HTTP Request and Reply Message

5. HTTP methods

15
 HTTP: An example of a request-reply protocol
 Hyper Text Transfer Protocol (HTTP) used by web browser clients to make
requests to web servers and to receive replies from them.
 Web servers manage resources implemented in different ways:
• as data – for example the text of an HTML page, an image or the class of an
applet;
• as a program – for example, servlets or PHP or Python programs that run on the
web server.

16
 HTTP (Cont’d)
 It supports a fixed set of methods (GET, PUT, POST, etc) that are applicable to all of
the server’s resources. Protocol allows for content negotiation and password-style
authentication:

• Content negotiation: Clients’ requests can include information as to what data

representations they can accept (for example, language or media type), enabling the
server to choose the representation that is the most appropriate for the user.

• Authentication: Credentials and challenges are used to support password-style

authentication. On the first attempt to access a password-protected area, the server
reply contains a challenge applicable to the resource.

17
HTTP (Cont’d)

 HTTP is implemented over TCP.

• The client requests and the server accepts a connection at the default
server port or at a port specified in the URL.
• The client sends a request message to the server.
• The server sends a reply message to the client.
• The connection is closed

 Persistent connections: connections that remain open over a series of request-

reply exchanges between client and server. A persistent connection can be closed
by the client or server at any time by sending an indication to the other
participant.

18
HTTP (Cont’d)
 Requests and replies are marshalled into messages as ASCII text strings, but
resources can be represented as byte sequences and may be compressed.
 Data resources are supplied as MIME-like structures in arguments and results.
Multipurpose Internet Mail Extensions (MIME), is a standard for sending multipart
data containing, for example, text, images and sound in email messages.

 HTTP methods
 GET: Requests the resource whose URL is given as its argument. If the URL refers to
data, then the web server replies by returning the data identified by that URL.
Arguments may be added to the URL; for example, GET can be used to send the
contents of a form to a program as an argument.
 HEAD: It does return all the information about the data, such as the time of last
modification, its type or its size.
 POST: Data supplied in the body of the request. the action may change data on the
server.

• providing a block of data to a data-handling process such as a servlet for example,

submitting a web form to buy something from a web site;

• posting a message to a mailing list or updating details of members of the list;

• extending a database with an append operation.

20
 HTTP methods (Cont’d)
 PUT: Requests that the data supplied in the request is stored with the given URL as
its identifier, either as a modification of an existing resource or as a new resource.

 DELETE: The server deletes the resource identified by the given URL.

 OPTIONS: The server supplies the client with a list of methods it allows to be
applied to the given URL and its special requirements.

 TRACE: The server sends back the request message. Used for diagnostic purposes.

• The operations PUT and POST are idempotent, but POST is not necessarily so
because it can change the state of a resource.

21
Remote Procedure Call
 Design issues for RPC
• the style of programming promoted by RPC – programming with interfaces
• the call semantics associated with RPC
• the key issue of transparency and how it relates to remote procedure calls

22
Remote Procedure Call (Cont’d)
 Benefits to Programming with Interfaces
• Programmers are concerned only with the abstraction offered by the service
interface and need not be aware of implementation details;

• Programmers also do not need to know the programming language or

underlying platform used to implement the service;

• Implementations can change as long as long as the interface remains the same.

23
 Remote Procedure Call (Cont’d)
 The definition of service interfaces is influenced by the distributed nature of the
underlying infrastructure:

• It is not possible for a client module running in one process to access the variables in
a module in another process.

• The parameter-passing mechanisms used in local procedure calls – for example, call
by value and call by reference, are not suitable when the caller and procedure are in
different processes. Call by reference is not supported.

• Addresses cannot be passed as arguments or returned as results of calls to remote

modules.

24
Remote Procedure Call (Cont’d)
 Interface definition languages (IDLs): are designed to allow procedures
implemented in different languages to invoke one another.

• An IDL provides a notation for defining interfaces in which each of the parameters
of an operation may be described as for input or output in addition to having its
type specified

25
 Remote Procedure Call (Cont’d)
 Called Semantic: doOperation can be implemented in different ways to provide
different delivery guarantees.

• Retry request message: Controls whether to retransmit the request message until
either a reply is received or the server is assumed to have failed.

• Duplicate filtering: Controls when retransmissions are used and whether to filter out
duplicate requests at the server.

• Retransmission of results: Controls whether to keep a history of result messages to

enable lost results to be retransmitted without re-executing the operations at the
server.

26
Remote Procedure Call (Cont’d)
 Call semantics (Cont’d)
 Maybe Semantics: the remote procedure call may be executed once or not at all.
• omission failures if the request or result message is lost;
• crash failures when the server containing the remote operation fails.

 At-least-once semantics: achieved by the retransmission of request messages, which

masks the omission failures of the request or result message.
• crash failures when the server containing the remote procedure fails;
• arbitrary failures – in cases when the request message is retransmitted, the remote
server may receive it and execute the procedure more than once, possibly causing
wrong values to be stored or returned.
 If the operations in a server can be designed so that all of the procedures in their
service interfaces are idempotent operations, then at-least-once call semantics may be
acceptable.

28
 Call semantics (Cont’d)
 At-most-once semantics: the caller receives either a result, the caller knows that the
procedure was executed exactly once, or an exception informing it that no result was
received, the procedure will have been executed either once or not at all.

 Transparency: Aimed to make remote procedure calls as much like local procedure calls as
possible, with no distinction in syntax between a local and a remote procedure call.

• All the necessary calls to marshalling and message-passing procedures were hidden from the
programmer making the call.

29
Implementation of RPC
 Implementation of RPC

 Client Process: accesses a service includes one stub procedure for each procedure in
the service interface.

• The stub procedure behaves like a local procedure to the client it marshals the
procedure identifier and the arguments into a request message, which it sends via its
communication module to the server. When the reply message arrives, it unmarshals
the results.

31
 Implementation of RPC
 Server Process: contains a dispatcher together with one server stub procedure and
one service procedure for each procedure in the service interface.

• Dispatcher selects one of the server stub procedures according to the procedure
identifier in the request message.

• Server Stub procedure then unmarshals the arguments in the request message, calls
the corresponding service procedure and marshals the return values for the reply
message.

• Service procedures implement the procedures in the service interface.

 Client and Server Stub procedures and the dispatcher can be generated
automatically by an interface compiler from the interface definition of the service.

32
Remote Method Invocation
 Commonalities between RMI and RPC
• They both support programming with interfaces, with the resultant benefits.

• They are both typically constructed on top of request-reply protocols and can
offer a range of call semantics such as at-least-once and at-most-once.

• They both offer a similar level of transparency that is, local and remote calls
employ the same syntax.

33
Remote Method Invocation (Cont’d)
 Differences between RMI and RPC
 The differences lead to added expressiveness when it comes to the programming of
complex distributed applications and services.

• The programmer is able to use the full expressive power of object-oriented

programming in the development of distributed systems software, including the
use of objects, classes and inheritance, and can also employ related object oriented
design methodologies and associated tools.

• Building on the concept of object identity in object-oriented systems, all objects

in an RMI-based system have unique object references, such object references can
also be passed as parameters, thus offering significantly richer parameter-passing
semantics than in RPC.

34
Remote Method Invocation (Cont’d)
 Design issues for RMI
• The key added design issue relates to the object model and, achieving the
transition from objects to distributed objects.

 Object model: Some languages (Java and C++), allow programmers to define
objects whose instance variables can be accessed directly.

• But for use in a distributed object system, an object’s data should be accessible
only via its methods.

1. Object references: Objects can be accessed via object references

2. Interfaces: provides a definition of the signatures of a set of methods without

specifying their implementation.

35
Remote Method Invocation (Cont’d)
 Design issues for RMI (Cont’d)
3. Action: is initiated by an object invoking a method in another object.
 An invocation of a method can have three effects:
• The state of the receiver may be changed.
• A new object may be instantiated, for example, by using a constructor in Java or C++.
• Further invocations on methods in other objects may take place.

36
Remote Method Invocation (Cont’d)
 Design issues for RMI (Cont’d)
4. Exceptions: Programs can encounter many sorts of errors and unexpected conditions
of varying seriousness.
• A block of code may be defined to throw an exception; another block of code that
catches the exception.

5. Garbage Collection: is necessary to provide a means of freeing the space occupied

by objects when they are no longer needed.
• A language such as Java, that can detect automatically when an object is no longer
accessible recovers the space and makes it available for allocation to other objects.
• When a language (C++) does not support garbage collection, the programmer has to
cope with the freeing of space allocated to objects.

37
Remote Method Invocation (Cont’d)

 Distributed Object: Distributed object systems may adopt the client-server

architecture.

• Replicated objects: to obtain the usual benefits of fault tolerance and enhanced
performance

• Migrated objects: to enhancing their performance and availability

38
Remote Method Invocation (Cont’d)
 The Distributed Object Model: Each process contains a collection of objects, some
of which can receive both local and remote invocations.
 Remote object references: Other objects can invoke the methods of a remote object
if they have access to its remote object reference.
• It is extended to allow any object that can receive an RMI to have a remote object
reference.

39
Remote Method Invocation (Cont’d)
 Remote interfaces: Every remote object has a remote interface that specifies
which of its methods can be invoked remotely.
• The class of a remote object implements the methods of its remote interface.

40
Remote Method Invocation (Cont’d)
 Actions in a distributed object system: When an invocation crosses the boundary of
a process or computer, RMI is used, and the remote reference of the object must be
available to the invoker.
• Object A needs to hold a remote object reference to object B. Remote object
references may be obtained as the results of remote method invocations.
• Object A might obtain a remote reference to object F from object B.
 When an action leads to the instantiation of a new object, that object will normally
live within the process where instantiation is requested

 Garbage collection in a distributed-object system: is generally achieved by

cooperation between the existing local garbage collector and an added module.
• If garbage collection is not available, then remote objects that are no longer required
should be deleted.

 Exceptions: Any remote invocation may fail for reasons related to the invoked object
being in a different process or computer from the invoker. 41
Implementation of RMI
Implementation of RMI (Cont’d)
 Communication module: The two cooperating communication modules carry
out the request-reply protocol, which transmits request and reply messages
between the client and server.
• The communication modules are together responsible for providing a specified
invocation semantics, for example at-most-once.
 Remote reference module: is responsible for translating between local and
remote object references and for creating remote object references.
• An entry for all the remote objects held by the process.
• An entry for each local proxy.
 Servants: is an instance of a class that provides the body of a remote object. It
is eventually handles the remote requests passed on by the corresponding
skeleton. Servants live within a server process.

43
Implementation of RMI (Cont’d)
 The RMI software
 Proxy: The role of a proxy is to make remote method invocation transparent to
clients by behaving like a local object to the invoker.
• It hides the details of the remote object reference, the marshalling of arguments,
unmarshalling of results and sending and receiving of messages from the client.
 Dispatcher: receives request messages from the communication module. It uses
the operationId to select the appropriate method in the skeleton, passing on the
request message.
 Skeleton: implements the methods in the remote interface.
• A skeleton method unmarshals the arguments in the request message and invokes
the corresponding method in the servant.

• It waits for the invocation to complete and then marshals the result, together with
any exceptions, in a reply message to the sending proxy’s method.

44
Implementation of RMI (Cont’d)
 Server and client programs: The server program contains the classes for the
dispatchers and skeletons, together with the implementations of the classes of all
of the servants that it supports.

• The client program will contain the classes of the proxies for all of the remote
objects that it will invoke. It can use a binder to look up remote object references.
 Factory methods
 Binder: Client programs generally require a means of obtaining a remote object
reference for at least one of the remote objects held by a server.
 Server threads: To avoid the execution of one remote invocation delaying the
execution of another, servers generally allocate a separate thread for the
execution of each remote invocation.

45
 Implementation of RMI (Cont’d)
 Activation of remote objects: A remote object is described as active when it is available for invocation within a
running process, whereas it is called passive if is not currently active but can be made active. A passive object
consists of two parts:
1. the implementation of its methods;
2. its state in the marshalled form.

 Persistent object stores: An object that is guaranteed to live between activations of processes is called a
persistent object.
• Persistent objects are generally managed by persistent object stores, which store their state in a marshalled form
on disk.

46
Implementation of RMI (Cont’d)
 Distributed Garbage Collection

• The process where the object lives (its server) should be informed of the new
proxy at the client.

• Then later when there is no longer a proxy at the client, the server should be
informed.

47
 RMI Project (CD + Book)

 Exercise
5.7 Discuss whether the following operations are idempotent:
i) pressing a lift (elevator) request button;
ii) writing data to a file;
iii) appending data to a file. Is it a necessary condition for idempotence that the operation should not be associated with any
state?

5.11 An Election interface provides two remote methods:

vote: This method has two parameters through which the client supplies the name of a candidate (a string) and the ‘voter’s
number’ (an integer used to ensure each user votes once only). The voter’s numbers are allocated sparsely from the
range of integers to make them hard to guess.
result: This method has two parameters through which the server supplies the client with the name of a candidate and the
number of votes for that candidate.
Which of the parameters of these two procedures are input and which are output parameters?

5.14 The Election service must ensure that a vote is recorded whenever any user thinks they have cast a vote. Discuss the
effect of maybe call semantics on the Election service. Would at-least-once call semantics be acceptable for the
Election service or would you recommend at-most-once call semantics?

5.22 A client makes remote method invocations to a server. The client takes 5 milliseconds to compute the arguments for
each request, and the server takes 10 milliseconds to process each request. The local operating system processing time
for each send or receive operation is 0.5 milliseconds, and the network time to transmit each request or reply message is
3 milliseconds. Marshalling or unmarshalling takes 0.5 milliseconds per message.
Calculate the time taken by the client to generate and return from two requests:
(i) if it is single-threaded;
(ii) if it has two threads that can make requests concurrently on a single processor.
You can ignore context-switching times. Is there a need for asynchronous invocation if the client and server processes are
threaded?