Remote Procedure Calls RPC

1
Remote Procedure Calls(RPC)

• Ref Tanenbaum/van Steen, 2.2
• Birrell Nelson

2
Outline

• Motivation
• RPC Mechanisms
• Stubs
• Data Marshaling
• Binding
• Writing Client/Server Code
• Asynchronous RPC

3
Introduction

• Goal hide communications from distributed
  programs to simplify usage of services
  implemented on another machine
• Basic idea Programs can call procedures (invoke
  services) that are implemented in another machine
• Synchronous caller is suspended until called
  procedure returns
• Why procedure calls?
• Provides familiar, clean, simple semantics
  (simplifies distributed programming)
• Provides type checking
• Higher level abstraction than network protocols
• In practice, RPC not same as procedure calls
• Widely used
• SUN RPC (system-level implementation)
• CORBA, DCOM, Java RMI, SOAP (application-level
  implementation)
• Here, discuss in context of client/server
  architectures
• Refer to caller as client
• Refer to callee as server

4
Conventional Procedure Call
C Example count read(fd, buf, nbytes)

• Call
• Copy params to stack in reverse order
• Procedure call (push return address)
• Allocate space for locals on stack

• Return
• Store return value in register
• Discard locals on stack
• Procedure return
• Discard parameters from stack

• Need to transfer control, pass parameters, and
  return results
• Call-by-reference pushes pointer to parameter
  (e.g., arrays) procedure can modify address
  space of caller
• Call-by-value parameter simply an initialized
  local variable in procedure modifying value
  parameter does not affect caller
• Call-by-copy/restore call-by-value copy values
  back in caller on return

5
Program Stubs

• Cannot directly call a procedure on a remote
  machine, so define stubs instead
• Client calls client stub residing on local
  machine that acts as a proxy for the remote
  procedure being called
• On server side, a server stub makes the actual
  call to the procedure (service) being invoked

6
RPC Mechanism
Client caller Server callee
(procedure) Client/Server stubs make interface
look like ordinary procedure call to both
client and server implementations

• Client calls client stub using normal (local)
  procedure call
• Client stub packs parameters into message, calls
  local OS
• Client's OS sends message to remote OS client
  blocks
• Remote OS gives message to server stub
• Server stub unpacks parameters, calls server via
  (local) procedure call
• Server does work, returns result to the server
  stub
• Server stub packs result into message, calls
  local OS
• Server's OS sends message to client's OS
• Client's OS gives message to client stub
• Stub unpacks result, returns to client

7
Design Issues

• Parameters and return results must be exchanged
  caller and callee may execute on different
  machine architectures
• What about differences in representation, e.g.,
  floating point representation? big-endian vs.
  little-endian?
• Client and server typically operate in different
  address spaces
• What about pointer parameters?
• Binding
• How does a client establish a connection to the
  server that implements the procedure (service) it
  is trying to call?
• Integration of RPC into existing programming
  languages caller and callee may be written in
  different languages
• Caller and/or callee may fail during this
  operation
• What should happen? What are the semantics of
  the RPC call?
• Security and authentication mechanisms

8
Passing Value Parameters
2-8

• Parameter marshalling packing parameters of the
  RPC into a message that can be sent to another
  machine
• Marshaling parameters implemented by client stub
• Unmarshaling parameters implemented at server
  stub
• Representation issues for heterogeneous platforms
• Different representation of data (e.g., EBCDIC
  vs. ASCII, 1s complement vs. 2s complement,
  floating point)
• Big-Endian (SPARC) vs. Little-Endian (Intel)
• Client and server must agree on encoding of
  parameters

9
Parameter Specification and Stub Generation

• A procedure
• The corresponding message.

• Client and server must agree on message format
• Must also agree on data encoding

10
Encoding Examples

• Sun RPC - External Data Representation (XDR)
• Implicit typing sender/receiver agree on order,
  single universal type for all data
• Canonical data representation defined for
  standard data types (boolean, char, short, int,
  etc.)
• Big-Endian (what did you expect?)
• All data must be encoded in XDR at sender,
  decoded at receiver
• What if a Little-Endian machine sends data to
  another Little-Endian machine?
• OSFs DCE Network Data Representation (NDR)
• Explicit typing type information included in
  data
• Supports multiple formats (e.g., ASCII EDCDIC
  characters, Big- and Little-Endian integers)
• Format label in message specifies type being used
• Up to receiver to decode data properly, convert
  if necessary
• More efficient for Little-Endian to Little-Endian
  machine communication

11
Passing Reference Parameters

• In general, very difficult! Often it is not
  supported
• Server needs to be able to read variables in
  callers address space
• Server may modify variables in callers address
  space
• Simple array (assume length known)
• Client stub copies (marshals) array into message
• Server stub copies array into buffer, calls
  procedure
• When procedure finished, server stub copies
  (marshals) the possibly modified array into
  message
• Client stub copies array back into callers
  address space
• General data structures
• Can traverse data structures to pack data -
  implies client stub can identify pointers
• Can generate remote operations for server
  accesses to client variables
• Computationally expensive

12
Binding

• Clients must be able to locate and connect to
  services it wishes to use
• Database of services is needed enumerating the
  service, and servers supporting them
• Possibly distributed
• Possibly with a search and registration protocol
• Set of naming conventions so that clients can
  specify what service they want

13
Binding Example

• Client-to-server binding in Distributed Computing
  Environment (DCE)

Server registration

• Server gets endpoint (port number) from DCE
  daemon serverendpointprotocols_supported
  registered in endpoint table
• Server name network address registered with
  directory service
• Get network address of server from directory
• Get endpoint information from DCE daemon
• DCE daemon has well known endpoint
• Invoke service via RPC

Client binds to server
14
Writing Client and Server Code

• Main pieces of software
• Client code that invokes RPC
• Server code that implements procedures
• Client stubs
• Server stubs
• RPC runtime system
• Writing stub code is tedious, error prone
• What RPC is trying to avoid in the first place!
• Means provided to automate generation of stub
  code
• Specify procedure interface in an Interface
  Definition Language (IDL)
• Define types, procedure interfaces using these
  types
• Think C function prototypes
• Specify one or more encodings (binary
  representation) of data
• IDL compiler compiles this specification into
  stub code
• Single vs. multiple language support
• Client (server) stub code linked with client
  (server) and runtime library to generate binary
  file

15
Example Distributed Computing Environment (DCE)
2-14

• Uuidgen generates globally unique identifier for
  interface
• Uses location time of creation to guarantee
  uniqueness
• Manually generate interface definition file (in
  IDL) specifying remote procedures, parameters,
  returned results
• Compile interface definition file to create (1)
  client stub code, (2) server stub code, header
  files included in both client and server
• Compile and link stub code with client/server
  implementation and runtime library

16
Asynchronous RPC
2-12

• Traditional RPC (a) Client must wait for server
  to complete operation no concurrency
• Not necessary for client to wait if service does
  not return any value
• Asynchronous RPC (b) client resumes after server
  acknowledges receipt
• Allows potential for concurrency between client
  and server
• Another variation Client does not wait for ack
  from server
• What if message is lost in network?

17
Asynchronous RPC With Return Value

• What if RPC returns a result, but client doesnt
  want to wait for it?
• Return result from RPC call asynchronously via
  interrupt
• Client and server interact through two
  asynchronous RPCs

18
Summary

• RPC an attempt to make distributed programming
  more like sequential programming
• Basic mechanisms
• Stubs
• Data marshaling
• Binding
• IDL for automated stub generation
• Asynchronous RPC
• Challenges
• Complexity, especially if different languages
• Performance