Implementing Remote Procedure Calls RPC Andrew D' Birrell Bruce Jay Nelson

1
Implementing Remote Procedure Calls (RPC) -
Andrew D. Birrell - Bruce Jay Nelson
Speaker Amit Kumar SahaHelper Rajnish
Kumar Expected length 45 mins
2
Introduction

• Method of Communication between distributed
  applications
• A possible implementation of an RPC package
• A brief overview of the performance of the
  proposed package

3
The contents of this talk

• Aim of a good RPC package.
• The design issues.
• The overall structure of the package.
• The binding of clients.
• The transport level communication protocol.
• Some other issues
• Performance and conclusion.

4
Aim of a good RPC package

• Efficiency
• Powerful semantics.
• Secure communication.
• Generality
• Optimize between the 1 2

5
The major design issues

• Semantics.
• Machine failure
• Communication failure
• Absence of shared address space
• Identification of caller and callee.
• Transport protocols for data and control
• Data integrity
• Security

6
The overall structure

• The environment
• Cedar programming environment
• Mesa language
• User
• User-stub

• RPC Runtime
• Server-stub
• Server
• Interface module
• A programmers point of view

7
The structural components interacting for a
simple call
Caller
Callee
User User-stub RPCRuntime importer
exporter interface
RPCRuntime Server-stub Server
importer exporter
interface
Local call Local return
Pack arguments unpack results
Transmit Receive
Receive Transmit
Unpack arguments pack results
Call return
Network
8
Overall structure contd...

• User-stub and Server-stub generated by a program
  called Lupine.
• RPC Runtime is the communication package
• Interface module is a list of procedures and
  names along with types of their arguments and
  result
• Enough for compile time checking

9
The binding of clients

• Naming of an interface which is exported for
  remote usage
• Location of the implementor of that interface
• The database used to keep this information

10
Naming

• Type of an interface
• Which interface the caller expects the callee to
  implement
• Instance of an interface
• Which particular implementor of the exported
  interface is desired
• Semantics of interface name not dictated by RPC
  Package.
• The way the name is used to locate an exporter is
  however dictated.

11
Location

• Grapevine distributed database is used.
• Keyed by a character string called Rname
• Two types of entries
• individuals
• For each there is a connect site ( a network
  address )
• groups
• A list of members or Rnames

12
Example

• Interface Bank has been exported
• 2 implementations
• Chase_Bank
• Implemented in machine with network address as
  NetAddr-1
• American_Bank
• Implemented in machine with network address as
  NetAddr-2

13
Example contd

• Group name would be Bank with member names
• Chase_Bank
• American_Bank
• Individual names would be
• Chase_Bank
• With connect site as NetAddr-1
• American_Bank
• With connect site as NetAddr-2

14
How it actually works

• Exporting an interface
• The server code call the server-stub
• Server-stub calls procedure ExportInterface in
  the RPCRuntime
• Given the interface name (type and instance)
• Procedure called dispatcher implemented in the
  server-stub which handles incoming calls for that
  interface

15
How it actually works contd...

• ExportInterface ensures
• Instance is one of the members of Grapevine group
  of the same type.
• The connect site of the individual is the network
  address of the exporting machine
• Might involve updating the database
• For each exported interface the RPCRuntime on
  that machine maintains a table
• Interface name
• The dispatcher procedure
• 32-bit machine relative identifier of the exporter

16
How it actually works contd...

• Importing and interface
• User code calls user-stub
• User-stub calls ImportInterface in the RPCRuntime
• Desired interface type
• Desired instance
• RPCRuntime contacts Grapevine
• If exporter exists RPCRuntime tries to bind to
  the machine that is supposed to export the
  interface according to Grapevine.

17
How it actually works contd...

• If the specified machine is actually exporting
  the interface then the identifier and the table
  index are returned
• Else the bind fails
• The exporter network address, identifier and the
  table index are remembered by the user-stub for
  future use
• In future calls the user-stub sends
• Unique identifier
• Table index
• Which procedure in the interface

18
How it actually works contd

• Variation in what is specified to ImportInterface
• Only the interface type
• All members of the group are returned
• RPCRuntime tries to locate the nearest running
  exporter.
• However the user can choose his own instance from
  the list that has been returned.
• Mention the network address directly
• Bypasses Grapevine

19
Exporting an Interface
Grapevine
Callee

RPCRuntime Stub Server
Do update
ExportA,B return
ExportA,B.
Record in table SetConnect Addmember
20
Importing an interface
Grapevine
Caller
Callee

User User-stub RPCRuntime
RPCRuntime
Lookup
GetConnect BindA,B
ImportA,B Record result
ImportA,B return
Table lookup
21
Communication protocol

• What semantics do we want to give for calls.
• Breakdown
• deadlock or loops
• Requirements
• Minimize the elapsed real time between a call and
  its result
• Not true for bulk data transfer protocols
• Minimize the load on the servers by substantial
  number of users

22
Communication protocol (Simple calls)

• Entire argument fits into a single packet.
• The results also fits into a single packet.
• Frequent such calls are being made.
• Caller send a call-packet containing
• Call identifier
• The required procedure
• The arguments of that procedure

23
Simple calls contd...

• The callee machine receives the packet
• The appropriate procedure is invoked
• When the procedure returns, a result packet is
  sent back.
• This result packet contains
• the same call identifier
• the result

24
Simple call contd

• The callee retransmits if acknowledgement is not
  received.
• The result is the acknowledgement
• The next call packet is acknowledgement that the
  previous result reached safely
• Explicit retransmission/acknowledgement packets
  may have to be sent

25
Simple calls contd...

• Call identifier
• Calling machine identifier (globally unique)
• calling process identifier (machine specific)
• sequence number (monotonic)
• The first two as a pair is termed as an activity

26
Simple calls contd...

• Each activity has at most one outstanding call
• RPCRuntime on a callee machine maintains a table
  giving the sequence number of the last call
  invoked by each activity

27
Packets during a simple call
Caller
Callee
User RPC Stub
RPC Stub Server
Call
Call
Send call packet await ack or result return
Do call return
Invoke procedure Send result
Result CallID , results
Network
28
Communication protocol(Complicated calls)

• The call requires more than one packet for the
  arguments or results.
• Sent in multiple packets.
• Each packet except the last one requests explicit
  acknowledgement.
• Call relative sequence number.
• Compares badly with bulk-data transfer protocols

29
Communication protocol(Complicated Calls)

• The arguments occupy two packets.
• The call duration long enough to require explicit
  acknowledgement.
• Since no subsequent calls arrived explicit
  acknowledgement of the result packet is required.

30
Caller
Callee
User RPC Stub
RPC Stub Server
CallCallID,Pkt0, pleaseACK,
Call result
Send call packet wait for ack build next
pkt Transmit it Wait for pkt Retransmit Wait
for ack Wait for result return Ack
Start arg record ack wait next pkt invoke
call acknowledge send result wait for
ack retransmit wait for ack idle
Do call return
AckCallID,Pkt0
DataCallID,Pkt1, dontACK,
DataCallID,Pkt1, pleaseACK,
AckCallID,Pkt1
ResultCallID,Pkt2, dontACK,
ResultCallID,Pkt2, dontACK,
AckCallID,Pkt2
31
Exception Handling

• Transmit an exception packet.
• These exceptions need to be defined in the
  respective interface.
• The RPCRuntime in the caller raises an exception
  in the appropriate process.
• If the catch phrase returns the result is sent to
  the callee and execution proceeds normally.

32
Exception handling contd...

• If catch phrase terminates with a jump then the
  callee procedure activations are unwound.
• RPCRuntime may raise call failed exception in
  case of communication difficulty.
• User can distinguish between local and remote
  calls.

33
Increasing efficiency

• By using processes
• By bypassing the layers of a normal protocol
  hierarchy
• Caller and Callee on the same network
• Could have used specialized packet formats

34
Increasing efficiency by using processes

• Idle server processes.
• Excess idle servers are killed if they were the
  result of a peak in call frequency.
• Call packets have source and destination process
  identifiers.

35
Increasing efficiency by using processes contd...

• Data structure shared with Ethernet interrupt
  handler.
• If destination process is waiting for an RPC
  packet it is sent to that.
• Else the packet is dispatched to the idle server
  process or a new process is created.

36
Performance

• 2 Dorado s running Cedar connected by an 2.94
  mbps Ethernet.
• Lightly loaded network (5 to 10)
• Time in microseconds and is elapsed time
• Calculated by dividing microprocessor cycles by
  known crystal frequency
• Accurate to about 10
• 12000 calls on each procedure.

37
Performance graphs

• The horizontal axis has no of arguments and
  results, each 16 bits long.
• The vertical axis has time in microseconds

38
Performance graphs contd...

• The horizontal axis has no of arguments and
  results, each 16 bits long.
• The vertical axis has time in microseconds

39
Performance graphs contd...

• The horizontal axis has the array size in words
  of the argument and the result.
• The vertical axis has time in microseconds

40
Performance graphs contd...

• The horizontal axis has the array size in words
  of the argument and the result.
• The vertical axis has time in microseconds

41
Performance graphs contd...

• The vertical axis has time in microseconds

42
Performance graphs contd...

• The vertical axis has time in microseconds

43
Conclusion (cons)

• Multicasting or broadcasting needs are not well
  satisfied.
• Does not work well enough for complicated calls.
• Not integrated with general purpose transport
  protocol

44
Conclusion (pros)

• Encourage the development of distributed
  applications as it is a low cost solution and
  quite general in concept.
• Strong and simple binding semantics.
• Simple , frequent calls handled efficiently.

45
Thats all folks.Thanks for listening to a 1983
paper!!!