Fundamentals Stream Session 2: ClientServer, RPC and RMI

1
Fundamentals Stream Session 2Client-Server, RPC
and RMI
Distributed Systems

• CSC 253
• Gordon Blair, François Taïani

2
Overview of the Session

• Introduction to the client-server model
• The key concept of remote procedure calls (RPC)
• What is RPC
• Styles of RPC
• Implementation considerations
• From RPC to RMI
• Essential characteristics
• Advanced features

Associated Reading Tanenbaum and van Steen, pp.
145-158, 68-98, 99-134
3
The Client-Server Model
Key
4
Example Servers

• Naming and trading services
• DNS service www.bbc.co.uk ? 212.58.224.89 (IP
  address)
• Service discovery protocol SLP, SDP, UPnP, Jini,
  etc.
• Distributed file service
• Samba (MS Windows), NFS (Network File Service)
  (UNIX)
• And many others (AFS, Coda, etc.)
• Security services Kerberos, etc.
• Time and coordination services
• NTP (network time protocol)
• Concurrency control and recovery services
• Etc.

5
What is RPC?

• Higher level mechanism supporting the
  construction of distributed applications (see
  also discussion on transparency later)
• Supports the calling of a procedure in a separate
  address space (process) as if it exists in the
  local address space the process may or may not
  be on the same machine
• But what is the semantics of a local procedure
  call?

6
RPC and Middleware
7
Styles of RPC

• First class RPC
• Integrated into the language gt normal language
  mechanisms can be used for exceptions etc
• Examples include Java RMI, Ada and Argus
• Second Class RPC
• A special Interface Definition Language (IDL) is
  used to define communications (see later)
• Language independence
• Examples include Sun RPC, CORBA and DCE

8
Asynchronous RPC
2-12

• The interconnection between client and server in
  a traditional RPC
• The interaction using asynchronous RPC

9
Programming with Interfaces

• Separation of interface and implementation
• Client software does not need to know the details
  of the implementation, cf. abstraction
• Important for platform and language independence
• Also important to support the evolution of
  software

10
Interface Definition Languages

• What is an IDL?
• A language independent means of specifyingan
  interface
• Similar to abstract data type specification
• Dealing with Parameters
• IN parameters value passed to server
• OUT parameters value returned from server
• IN/OUT parameters combination of above

11
Example CORBA IDL
interface inventory // attributes and type
definitions const long MAX_STRING 30
typedef long part_num typedef long
part_price typedef long part_quantity
typedef string part_nameltMAX_STRING1gt struct
part_stock part_quantity max_threshold
part_quantity min_threshold part_quantity
actual //end of part_stock
p.t.o.
12
CORBA IDL (continued)
// operations boolean is_part_available(in
part_num number) void get_price (in
part_num nmb , out
part_price price ) void get_stock (in
part_num number , out
part_quantity quantity) long order_part(in
part_num number , inout
part_quantity quantity, in
account_num account ) //end of interface
inventory
13
The Issue of Transparency

• Definition
• Transparency (as defined in session 1) refers to
  the property of hiding aspects of distribution
  from the user, e.g. location and access
  transparency
• Transparency in RPC
• Ultimate goal, but generally compromised by
• Overall cost of an RPC
• Every remote call will cost O(1-10)ms
• Extra exceptions that are raised
• Parameter passing is different, e.g. pointers

14
Implementing RPC
N.B. Proxies, stubs, dispatchers are generated
automatically by an appropriate IDL compiler
15
Key Components Client Side

• Proxies (see also smart proxies)
• Masquerades as a local version of the remote
  interface
• Redirects calls to client stubs
• May perform other actions (smart proxies)
• Client stubs
• Carries out marshalling (flattening) of calls and
  the requests the retransmission of the message
• Also must unmarshal returning replies

16
Key Components Server Side

• Dispatchers
• Receive incoming messages and direct them to an
  appropriate server stub
• Server stubs (skeletons)
• Unmarshals message and then invokes appropriate
  code body
• Must also marshal reply values and initiate
  transmission back to the client

17
Focus on Underlying Protocol

• Task
• You are asked to design the communications module
  for RPC which will provide a protocol that mimics
  the semantics of a local call
• Problems
• Request message may get lost
• Reply message may get lost
• Client may crash
• Server may crash

N.B. This assumes you are implementing over an
unreliable protocol such as UDP. In practice, RPC
can equally be implemented over TCP, especially
in large scale systems.
18
Lightweight Protocols

• Maybe
• Send request to server which sends back a reply
• No real guarantees at all if anything goes wrong
• At least once
• Sends message and if reply not received after a
  given time, the message is re-sent (failure
  assumed after n re-sends)
• Will guarantee the call is made at least once,
  but possibly multiple times
• Ideal for idempotent operations

19
At Most Once Protocols
Client
Server
Call
Re-send
20
From At Most Once to Exactly Once

• Semantics
• The remote procedure call will be carried out
  once (completely) or not at all (the operation
  will be aborted)
• Approach
• Builds on at most once protocol
• Requires additional support for atomicity

See lectures on fault tolerance and dependability
21
From RPC to RMI

• Common organization of a remote object with
  client-side proxy.

2-16
But what are the essential differences?
22
Essential Characteristics of RMI

• Full integration with object-oriented programming
  language
• Ability to exploit objects, class and inheritance
• Added benefits from exploiting built in
  (object-oriented) approaches to, for example,
  exception handling
• From procedure calling to method invocation
• Added expressiveness of supporting object
  references
• More sophisticated options for parameter passing
• E.G. See lecture on Java RMI
• Pass by (object) reference
• Pass by value (exploiting serialisation)
• Often integrated with code (object) mobility
• E.G. Use of class loading in RMI

See lectures on Java RMI and on code mobility and
Aglets
23
Advanced Features

• Static vs. dynamic invocation
• Static invocation is the default and assumes that
  interfaces are known at compile time (stubs are
  compiled from the IDL)
• Any changes in the system require re-compilation
• Dynamic invocation in contrast is used when
  unanticipated classes of object are discovered at
  run-time (programmer must compose the invocation
  explicitly
• Object adapters
• Provide a wrapper around an object or set of
  objects to present a common abstraction, e.g. to
  hide heterogeneity
• At its most sophisticated, an object adapter can
  encapsulate policies for dispatching, thread
  allocation, object activation and passivation and
  object persistency
• Such advanced features are most commonly found in
  more advanced distributed object platforms such
  as CORBA

24
More on Object Adapters

• This diagram shows a server with different object
  adapters each supporting a set of objects
• Each adapter can implement its own policies
  suitable for that category of object (see
  previous slide)

25
Alternative Approaches 1 Beyond Client-Server

• Can we move from a world of clients and servers
  to a world of peers co-operating on a given task
  (i.e. peer to peer)
• In this new world, can we re-create all the
  services that users of a distributed system
  expect
• Routing
• Searching and discovery
• Distributed file sharing
• Group communication
• What impact does this have on key properties
• Scalability
• Dependability

26
Alternative Approaches 2 Beyond RPC/ RMI

• Can we move from the rather synchronous world of
  RPC or RMI towards more asynchronous modes of
  interaction
• Message passing, e.g. MPI
• Event communication/ publish-subscribe
• Tuple space communication
• Or, can we hide distribution more thoroughly by
  presenting one world-wide address space
• Distributed shared memory
• What impact does this have on key properties
• Scalability
• Dependability

27
Expected Learning Outcomes

• At the end of this session
• You should understand the concept of RPC and the
  various styles of RPC that area available
• You should appreciate the issues involved in the
  design of an RPC service, e.g. transparency
• You should also appreciate how modern RPC
  services may be implemented, including the key
  architectural elements involved
• You should understand the essential
  characteristics of RMI and how this adds value to
  RPC-based approaches
• You should also be aware of characteristics of
  more advanced distributed object systems
• You should be aware of alternative approach to
  those presented in this lecture, especially P2P
  approaches, asynchronous communication models and
  also approaches based on distributed shared memory