Remote Procedure Call

1
Remote Procedure Call

• CISC 879 Spring 03
• Tam Vu (tvu_at_mail.eecis.udel.edu)
• March 06, 03

2
Outline

• Introduction
• RPC mechanisms
• Design issues
• Programming with RPC
• Case study SUN RPC

3
Introduction

• Problem with sockets
• Socket interface is straightforward
• Connect
• Read/write
• Disconnect
• Forces read/write mechanism
• Not how we generally program
• We usually use procedure calls
• To make distributed computing look more like
  centralized
• I/O is not the way to go

4
Introduction

• 1984 Birrell Nelson
• Mechanisms to call procedures on other machines
• Processes on machine A can call procedures on
  machine B
• A is suspended
• Execution continues on B
• When B returns, control passed back to A
• Goal it appears to the programmer that a normal
  call is taking place

5
Introduction

• Remote Procedure Call (RPC) is a high-level model
  for client-sever communication.
• RPC enables clients to communicate with servers
  by calling procedures in a similar way to the
  conventional use of procedure calls in high-level
  languages.
• Examples File service, Authentication service.

6
The RPC model
7
RPC Mechanisms

• The client transfer call request (the procedure
  name) and the arguments to the server via client
  stub function
• stub function
• marshals arguments and places them into a message
  together with the remote procedure identifier.
• Sends message to server and waits for call return

8
RPC Mechanisms

• Server receives the call request and passes to an
  appropriate server stub function.
• server stub function unmarshals the arguments,
  call the corresponding (local) service procedure.
• On return, the server stub marshals the output
  arguments into a call return message and sends
  back to the client.

9
RPC Mechanisms

• Client stub receives call reply, unmarshals
  value, returns to client code

10
RPC Mechanisms
11
Benefits

• Familiar procedure call interface
• Writing applications is simplified
• RPC hides all networks codes
• Programmers dont have to worry about details
  (sockets, port numbers, byte ordering)
• RPC presentation layer in OSI model

12
Characteristics

• The called procedure is in another process which
  may reside in another machine.
• The processes do not share address space.
• Passing of parameters by reference and passing
  pointer values make no sense.
• The called remote procedure executes within the
  environment of the server process.
• The called procedure does not have access to the
  calling procedure's environment.

13
Design issues
14
Parameter passing

• By values
• easy, just copy data to network message.
• By reference
• makes no sense without shared memory
• Trick
• Copy items referenced to message buffer
• Ship them over
• Unmarshal data at server
• Pass local pointer to server stub function
• Send new value back

15
Representing data

• No such things as incompatibility on local
  systems
• Remote machine may have
• Different byte ordering
• Different sizes of integers and other types
• Different floating point representations
• Different character sets
• Need standard encoding to enable communication
  between heterogeneous systems

16
Representing data

• Implicit typing
• Only values are transmitted, not data type or
  parameter information
• E.g., Sun XDR (eXternal Data Representation)
• Explicit typing
• Types are transmitted with values
• E.g., ISO ANS.1, XML

17
Binding

• How to locate host and server process?
• Solution 1 use a central DB
• Server sends message to central DB indicating the
  services it can offer
• Clients contact this authority whenever they need
  to locate a service
• Solution 2
• Client needs to know server name
• Server maintains a DB of available services

18
Failures

• Local procedure calls do not fail
• If they core dump, the entire process dies
• RPC is more vulnerable to failure
• Server could generate errors
• Problems in network
• Server crash
• Client crash while server is still running code
  for it
• Transparency breaks here
• Applications should be prepared to deal with RPC
  failure

19
Delivery guarantees

• Retry request message
• Client retransmits the request message until
  either a reply or the server is assumed to have
  failed.
• Duplicate filtering
• server filters out duplicate message.
• Retransmission of replies
• Server keeps a history of reply messages to
  enable lost replies retransmitted without
  re-executing the server operations.

20
Call Semantics

• Semantic of local procedure calls exactly-once
• Exactly-once maybe difficult to achieve with RPC
• At-least-once
• The client assumes that the RP is executed at
  least once (on return from the RP).
• Can be implemented by retransmission of the
  request message on time-out.
• Acceptable only if the servers operations are
  idempotent. That is f(x) f(f(x)).

21
Call Semantics

• At-most-once
• When a RPC returns, the remote procedure (RP) is
  assume to have been called exactly once or not at
  all.
• Implemented by the server's filtering of
  duplicate requests and caching of replies.

22
Call Semantics

• At-most-once
• This ensure the RP is called exactly once if the
  server does not crash during execution of the RP.
  
• When the server crashes during the RP's
  execution, the partial execution may lead to
  erroneous results.
• In this case, we want the effect that the RP has
  not been executed at all.

23
Call Semantics
24
More issues

• Performance
• remote procedure call and return time can be
  significantly slower than that for local
  procedure call (1 - 3 orders of magnitude).
• Security
• Messages visible over the network
• Authenticate client
• Authenticate server

25
Programming with RPC

• Most languages (C, C, Java,) have no concept
  of remote procedure calls
• Language compilers will not generate client and
  server stubs
• Common solution
• Use a separate compiler to generate stubs
  (pre-compiler)

26
Programming with RPC

• Interface Definition Language
• Allow programmers to specify remote procedure
  interfaces (names, parameters, return values)
• Pre-compiler can use this to generate client and
  server stubs
• Marshalling code
• Unmarshalling code
• Network transport protocols
• Conform to defined interface

27
Programming with RPC

• Client code has to be modified
• Initialize RPC-related options
• Transport type
• Locate host/service
• Handle failure of remote procedure call
• Server functions
• Generally need little or no modification

28
Case Studies SUN RPC

• Interface definition language XDR
• a standard way of encoding data in a portable
  fashion between different systems
• Pre-compiler rpcgen
• A compiler that takes the definition of a remote
  procedure interface, and generates the client
  stubs and the server stubs
• Communication handling TCP or UDP

29
References

• http//www.cisco.com/univercd/cc/td/doc/product/so
  ftware/ioss390/ios390rp/rprpcgen.htm
• http//pandonia.canberra.edu.au/OS/l14_1.html
• http//www.cs.cf.ac.uk/Dave/C/node33.html

30
Thank you!