Yang YU (yyu@cs.ucsd.edu)
Mon, 15 May 2000 23:26:08 -0700

Performing Remote Operations Efficiently on a local computer Network

Main point:
remote reference/operation model that serves as the foundation of an
efficient LAN, with implementation considerations.

1. how to reduce the high processing overhead of network
communication, thus enabling fine granularity of parallelism
2. Build an efficient communication subsystem on which to base
language primitives.

Features of the subsystem:
1. integrated implementation instead of layered approaches(wants to
be more efficient)
2. ensuring that the functions provided are suitable for
implementing high level primitives.

Remote Reference/ Remote operation Model
Caller: Remote refrence;(Client, master)
Callee: Remote Operation(Server, slave)
4 reasons for this model:
Primitives base on this model can be efficient
Support for Reliability
Potential for protocol simpification
Potential for efficient
description of Model:
Reference commit -> Op-Begin-Commit->Op-End-Commit -> (Result -
Five attributes associated with Reference :
Reliablity; 4
Value and Novalue reference;
Synchrony: 3
Inter-reference flow control
Operation Types: primary/ secondary

Implementation Consideration
Session and socket
Session is over a single master and a single slave
a socket is on each of the master and slave processes
3 functions
2 types
4 major operaitons during a session.
Implementations of Synchorny/Reliability

Only-Once-Type-2: asynchronous references
Only-Once-Type-1: primary, processor-synchronous references

Implementing Remote Procedure Calls

Main Point
Over all structures of RPC mechanism and facilities for binding
RPC clients, and transportation level protocols.

1.simplify building distributed systems
2.balance between powerful semantics and efficiency
3.secure communications
4.similarity between semantics of RPCs and LPCs

Major issues
1.precise semantics
2.integration of remote calls into existing programming systems
4.suitable transport protocols
5.data integrity and security in an open communication network

2.user-stub: place a specification of the target procedure and the
arguments into packet
3.RPCRuntime: transmission, acknowledges,packet routing, encryption
4.server stub: unpack data, and invoke the corresponding procedure

1.Naming: type and instance
2.Alternatives for locating an exporter :
broadcast protocol
including in application programs the network addresses of the
Grapevine distributed database:
Group entry: {RName, list of members' RNames}
Individual entry: {RName,connect-site}
Each machine maintains all the exported interfaces of the
form {interface name,
dispatcher, ID}
ID is unique by using successive 32-bit counter initialized
to the real time clock
and constrained to be less than the current value of the
clock. This constrains the
average rate of calls < 1/sec.
If binding succeeds the user-stub remembers :
exporter network address
table index of the interface
At each call the call packet contains :
table index of the desired interface
entry point of the desired procedure
Importing an interface does not affect data structures from the
exporter machine
Binding breaks if the exporter crashes and restarts because of
the use of ID
Calls only on procedures that have been explicitly exported
through RPC
Restrict the set of users to export particular interface by
using access controls that
restrict updates to the database

Transport protocol

1.Features and Goals
There are substantial gains available if one designes and
implements a transport
protocol especially for RPC
Minimize the elapsed real-time between initiating a call and
getting results
Minimize the load imposed on a server by substantial number of
Minimize state information and the time to set up a connection
Exactly once and at most once
2.Call features
Call identifier {machine ID, calling process ID, monotonic
sequence no}
Calee machine maintains the sequence number of the last call i
nvoked by each activity
{ machine identifier, process }
Call packet { call identifier, data specyfing the procedure,
arguments }
Result packet { call identifier, results }
There is no special establishment connection protocol ( receive
from unknown activity
creates connection implicitly)
The server discards its state information for a connection idle
for long
To ensure unique identifier even after a crash, conversation ID
based on 32-bit clock is
passed as well as the call sequence number on every call. (Any
better alternative?)
Using probe packets to detect failure of communications and
server process
Require one acknowledge for each packet except the last one (Too
inefficient!!! Any
better solution? )
maintain a stock of idle server processes to avoid process
reduce the number of process switches involved in a call
use subsequent packet to implicitly acknowledge the previous
design a transport protocol that suits RPC best ( bypass
software layers that correponds
to the normal layers of a protocol hierarchy )

Yang Yu
Department of Computer Science and Engineering
University of California, San Diego