NAMING - Way2mca
Download
Report
Transcript NAMING - Way2mca
Remote Procedure
Call (RPC)
The Programming Model
Remote Subroutine
Client
……………………
bar = foo(a,b);
…………………
Server
int foo(int x, int y )
{
if (x>100)
return(y-2);
else if (x>10)
return(y-x);
else
return(x+y);
}
RPC
Remote Procedure Call (RPC) is a powerful, robust, efficient,
and secure interprocess communication technique for
creating distributed client/server programs. It makes
client/server interaction easier and safer by handling common
tasks, such as security, synchronization, data flow.
It enables data exchange and invocation of functionality
residing in a different process. That different process can be
on the same machine, on the local area network, or across
the Internet.
RPC(Remote Procedure Call) is a way to
– hide communication details behind a procedural call so
user does not have to understand the under layer network
technologies
– bridge heterogeneous environments
RPC presumes the existence of a low-level
transport protocol, such as TCP or UDP, for
carrying
the
message
data
between
communicating programs.
Issues Handled by RPC
How to invoke service in a more or less transparent manner.
How to exchange data between machines that might use
different representations for different data types.
– data type formats (e.g., byte orders in different
architectures)
– data structures (need to be flattened and the
reconstructed)
How to find the service one actually wants among a
potentially large collection of services and servers.
– Client should not know where the server resides or even
which server provides the service.
How to deal with errors in the service invocation:
– server is down, communication link broken, server busy,
duplicated requests etc.
Features of RPC
Simple call syntax
Semantics similar to local procedure call
Specification of well defined interface
Clean and simple semantics
Efficient
Used in heterogeneous environment
RPC Model
Caller (client)
Call procedure
and wait for reply
Callee (server)
Receive message
Receive request and start
procedure execution
Procedure executes
Send reply and wait for
next request
Resume
execution
Reply message
RPC Model
Extension of the procedure call mechanism; Called
procedure can be on remote computer.
The remote procedure has no access to data and
variables of the caller’s environment, as the caller
and the callee processes have disjoint address
spaces.
Message-passing scheme is used for information
exchange between the caller and the callee
processes.
Transparency of RPC
Local procedures & remote procedures are indistinguishable
to programmers. This requires:
– Syntactic Transparency
– Semantic Transparency
Semantic Transparency difficult to achieve because:
– Address space of calling process & called process
disjoint.
– Remote procedure calls need the ability to take care
possible processor crashes & communication problems
network.
– Remote procedure calls take more time due
involvement of communication network.
is
of
of
to
How RPC Works
Elements of RPC
The RPC elements make it appear to users as though a
client directly calls a procedure located in a remote server
program.
• The client
• The client stub
• The RPC Runtime
• The server stub
• The server
•
To conceal the underlying RPC system from both client &
server processes, a separate stub procedure is associated
with both processes. It provides local procedure call
abstraction.
•
RPC communication package, RPC Runtime hides the
existence & functional details of underlying network.
Client
– A process, such as a program or task, that requests a
service provided by another program. The client process
uses the requested service without having to deal with
many working details about the other program or the
service.
Client Stub
– Module within a client application containing all of the
functions necessary for the client to make remote
procedure calls using the model of a traditional function
call in a standalone application. Performs following
functions :–
– On a request from client, packs a specification of target
procedure & arguments into a message & asks local RPC
Runtime to send it to server stub.
– On receipt of procedure execution, it unpacks result &
passes it to client.
RPC Runtime
– Handles transmission across the network between client
and server machine.
– It is responsible for retransmissions, acknowledgment,
packet routing and encryption.
Server Stub
– Module within a server application or service that contains
all of the functions necessary for the server to handle
remote requests using local procedure calls.
– On receipt of call request, it unpacks it and makes a
normal call to invoke the procedure in the server.
– On receipt of the result of procedure execution, it packs
the result into a message and ask the RPCRuntime to
send it to the client stub.
Server
– A process, such as a program or task, that responds to
requests from a client.
RPC Procedure
1. Client makes a procedure call.
2. Client stub retrieves the required parameters from the client
address space.
3. Translates the parameters as needed into a standard format
(NDR Network Data Representation) for transmission over
the network.
4. Calls functions in the RPC client run-time library to send the
request and its parameters to the server.
5. The server RPC run-time library functions accept the request
and call the server stub procedure.
6. The server stub retrieves the parameters from the network
buffer and converts them from the network transmission
format to the format the server needs.
7. The server stub calls the actual procedure on the server.
8. The remote procedure then runs, possibly generating output
parameters and a return value. When the remote procedure
is complete, a similar sequence of steps return the data to
the client.
9. The remote procedure returns its data to the server stub.
10. The server stub converts output parameters to the format
required for transmission over the network and returns them
to the RPC run-time library functions.
11. The server RPC run-time library functions transmit the data
on the network to the client computer.
12. The client RPC run-time library receives the remoteprocedure return values and returns them to the client stub.
13. The client stub converts the data from standard format to the
format used by the client computer. The stub writes data into
the client memory and returns the result to the calling
program on the client.
14. The calling procedure continues as if the procedure had
been called on the same computer.
Stub Generation
Manually
– A set of translation functions are provided from
which the user can construct his own stub.
Automatically
– Uses Interface Definition Language to define
interface between client & server
Where Stubs Come From
Interface Definition Language
– Specification language used to describe a software
component's interface. IDL is a purely declarative
language. Defines only types and procedure headers.
– IDLs describe an interface in a language-neutral way,
enabling communication between software components
that do not share a language – for example, between
components written in C++ and components written in
Java.
– IDLs offer a bridge between the two different systems in
RPC.
– The IDL specifies the names, parameters, and types for
all client-callable server procedures. An interface compiler
is then used to generate the stubs for clients and servers
(appropriate marshalling/ unmarshalling operations &
header file that supports data type in interface definition).
Interface stateless_fs
{
void read
(
[in] Filename
[in] long
[in,out] long
[in] Buffer
);
void write
(
[in] Filename
[in] long
[in,out] long
[in] Buffer
);
}
filename;
position;
nbytes;
buffer;
filename;
position;
nbytes;
buffer;
RPC Messages
Call messages
– Remote procedure identification
– Arguments
– Message identification (sequence no)
– Message type (call / reply)
– Client identification
Remote procedure identifier
Message Message Client
Program Version Procedure Arguments
identifier type
identifier
number number number
Reply messages.
Following conditions could occur:
– Call message is not intelligible. Server rejects such calls.
– Client is not authorized. Server returns unsuccessful reply.
– Remote procedure specified not available with server.
Unsuccessful reply.
– Unable to decode supplied arguments.
– Exception occurs while executing.
– Procedure is executed successfully & reply sent back.
Message Message Reply status
identifier type
(successful)
Result
Reason
Message Message Reply status
(unsuccessful) for
identifier type
failure
Marshaling Arguments and Results
Marshalling is the packing of procedure parameters into a
message packet( Encoding/ Decoding). It involves:
– Taking arguments or result.
– Conversion of program objects (language level data
structures) into stream.
– Reconstruction of program objects from stream
Marshaling procedures are of two types
– Provided as part of RPC software
• Used for scalar & compound data types
– Defined by users of RPC system
• Used for user-defined data types & pointer type
Server Management
Stateful Server
– Maintains client’s state information from one rpc call to
another. Client’s state information is subsequently used at
time of execution of second call.
– Server gives the client a connection identifier unique to
the client. Identifier is used for subsequent accesses until
the session ends. Server reclaims main-memory space
used by clients that are no longer active.
Open ( filename ,mode)
Read(fid, n , buffer)
Write ( fid, n ,buffer)
Seek ( fid , position)
Close ( fid )
Stateful File Server
Client process
Server process
Open(filename,mode)
Return (fid)
fid
Read (fid, 100, buf)
Return ( bytes 0 - 99)
Read (fid, 100, buf)
Return(bytes 100-199)
mode
R/W
pointer
Example of stateful server
With a protocol such as ftp, there is a need for the
server to keep track of the progress of the session,
such as which block of the file needs to be fetched
next. A server does so by maintaining a set of state
for each session, known as the session state data.
For the file transfer protocol, the session state data
may include the name of the file being transferred,
and the current block count.
Stateless Server
– Does not maintain any client information. Every
request from a client must be accompanied with
all necessary parameters to successfully carry
out the desired operation, i.e. every request is
self-contained.
– No need to establish and terminate a connection
by open and close operations.
Read (filename, position, n, buffer)
Write (filename, position, n, buffer)
Stateless File Server
Client process
Server process
File state
information
fid
R/W
mode pointer
Read (filename, 0,100,buf)
Return (0 to 99 bytes)
Read (filename,100,100, buf)
Return (100 to 199 bytes)
Stateful vs Stateless Server
Stateful Server
– Relieve client from keeping track of state information.
– Fewer disk accesses.
– If a file is opened for sequential access, can read ahead
the next blocks.
– If server crashes, client can get inconsistent results.
– If client crashes, its information held by server may no
longer be valid.
Stateless Server
– Better equipped to handle failure
Server Creation Semantics
RPC servers can be classified on the basis of time
duration for which they survive.
Instance-per-call servers
Instance-per-transaction /session servers
Persistent servers
Instance-per-call servers
Exist only for duration of single call.
Created by RPCRuntime on the server machine
only when call message arrives.
Deleted after call execution
Server is exclusively used by a single client.
Disadvantages
– They are stateless. Thus intercall
information has to be maintained by
client process or the supporting OS.
– Overhead in server creation/ deletion if
type of service invoked several
successively.
state
either
same
times
Instance-per-Session Servers
Exist for the entire session for which a client and a server
interact – can maintain intercall state information.
Server managers for each type of service are registered with
the binding agent.
Client specifies the type of service required to binding agent,
which returns address of appropriate server manager.
Client contacts the concerned server manager, which spawns
a new server and passes back the address to the client.
When session gets over, client informs server manager &
server is destroyed.
Server is exclusively used by a single client.
Persistent Server
•
•
•
•
Remain in existence indefinitely.
Can be shared by many clients.
Created and installed before the clients.
Each server registers its service with the binding
agent.
• When client contacts binding agent for a particular
type of service, it returns address of appropriate
server to the client.
• Server interleaves requests from a number of
clients, so has to concurrently manage several
sets of state information.
Parameter-Passing Semantics
Call by value
– All parameters are copied into a message that is
transmitted from the client to the server.
– Not suitable for passing parameters involving voluminous
data.
Call by reference
– Passing pointers or passing parameters by reference is
meaningless.
– Used in distributed shared memory systems.
– Call by object reference
– Call by move
– Call by visit
Call semantics
Call semantics of an RPC system determines how remote procedure
may be executed in case of failure.
Possibly or May-Be call Semantics
– Weakest semantics – no fault tolerance measures
– Caller waits for predetermined timeout period & then continues
with its execution.
– No guarantee of receipt of message.
Last-One call Semantics
– Client retransmits requests based on timeouts until a response is
received by it.
– Result of last executed call is used by the caller.
– Difficult to achieve when more than 2 processors involved.
– Orphan calls (whose parent (caller) has expired due to node
crash) causes problem.
– The orphan calls must be terminated before restarting the
crashed process.
Last of Many call Semantics
– Orphan calls neglected.
– Call identifiers uniquely identify each call.
– Caller accepts a response only if its call identifier matches
with identifier of most recently repeated call.
At least one call Semantics
– Guarantees one or more executions by using timeout
based retransmissions.
– Caller accepts first response message.
Exactly Once call Semantic
– Eliminates the possibility of a procedure being executed
more than once no matter how many times a call is
retransmitted.
Ensuring Idempotency
Each client request is made self-contained & server
is made stateless.
ReadNextRecord ( Filename )
ReadNextRecord ( Filename, N )
AppendRecord (Filename , Record)
N= GetLastRecordNo( Filename)
WriteRecordN( Filename, Record, N)
Ques. Which operations are idempotent? If not give
semantics to make them idempotent.
1. Read_record (filename, rec_no)
2. Append_record (filename, record)
3. A=sqrt(625)
4. Mpy (integer1, integer2)
5. Increment (integer)
6. Increment (var)
7. Seek (filename, position)
8. Read_next_record (filename)
9. Write_record (filename)
10. Add (sum, 30)
11. T= time(x)
o
o
o
o
o
o
Append_record (filename, record)
- N= GetLastRecordNo ( Filename)
- WriteRecordN ( Filename, Record, N)
Increment (var)
- Var = initial_value
- Increment (var)
Read_next_record (filename)
- Read_record (filename, rec_no)
Write_record (filename)
- Write_record (filename,after_record, record)
Add (sum, 30)
- sum = initial_value
- Add (sum, 30)
T= time(x)
- T = time (Of_particular_event)
Communication protocol for RPC
• Request (R) Protocol
Server
Client
First RPC
Next RPC
Request
message
Request
message
Procedure
execution
Procedure
execution
Communication protocol for RPC
Request (R) Protocol
– No acknowledgement/ reply required
– Client not blocked on sending request
– 1 message per call
– May-be call semantics
– No retransmission of request
– Asynchronous – improves server (no reply
generation) / client (not blocked) performance
– UDP used – unreliable, TCP used – reliable
– Ex: Distributed windows system, Periodic
update services
Request/Reply (RR) Protocol
Client
Server
Request message
First RPC
Reply Message
Procedure
execution
Serve as ack for req msg
Next RPC
Request message
Serve as ack for reply of
previous RPC
Serve as ack for req msg
Procedure
execution
Request/Reply (RR) Protocol
Implicit acknowledgement
Transmit 2 packets per call.
Used for simple RPC’s. Simple RPC is one in
which all arguments & results fit in a single packet
buffer & duration of a call & interval between calls
are short.
Client retransmits request if it does not receive
response message before a predetermined timeout
period elapses. Can lead to duplicate executions.
At least once or exactly once call (if use reply
cache) semantics.
Request/Reply/Acknowledge - Reply
(RRA) Protocol
Client
Server
Request message
First RPC
Reply Message
Procedure
execution
Reply ack msg
Request message
Next RPC
Reply Message
Reply ack msg
Procedure
execution
Request/Reply/Acknowledge - Reply
(RRA) Protocol
Three messages per call
Difficult to maintain reply cache if multiple clients,
so this helps implement exactly once call
semantics
Server deletes reply of a request from reply cache
only after it gets its acknowledgement
All three messages have same message identifier
Loss of acknowledgement message harmless as it
is cumulative
Complicated RPC
RPCs involving long-duration calls or large gaps between
calls.
– Periodic probing of server by the client helps detect
server’s crash or communication link failure. Message
identifier included in probe packet.
– Periodic generation of an acknowledgment by the server
is done if duration of call is long.
RPCs involving arguments/results that are too long to fit in a
single-datagram packet.
– Several physical RPC’s for one logical RPC. Overhead
involved with each RPC.
– Use multidatagram messages. Single acknowledgement
message for all packets.
Client-Server Binding
The process by which a client (importer) becomes
associated with a server (exporter) so that calls can
take place is known as binding.
Various issues:
– How does client specify server to which it wants
to bind with?
– How to locate specified server?
– When to bind client with server?
– Can binding change during execution?
– Can client bind with multiple servers that provide
same service?
Server Naming
How does client specify server to which it wants to
bind with?
Specification by a client of a server.
Interface name – type & instance (optional).
// file_server, instance of file server
Interface name is unique identifier of server.
Type of interface also has a version number to
distinguish between old & new versions of
interface.
Server Locating
How to locate specified server?
Broadcasting –
– A message to locate the desired server is
broadcasted to all the nodes from the client
node.
– Suitable for small networks.
Binding agent –
– Name server which is used to bind a client to a
server by providing the client with thelocation
information of the desired server.
– Binding table is maintained to do the mapping
of interface name and its locations.
Binding agent
Binding agent’s location known to all nodes. Fixed
address or broadcasted to all.
Binding agent
(2) Lookup
server location
(1) Register/
Deregister
(3) Server
location
Client process
Server process
(4) Call server
Binding agent
Advantages
– Can support multiple servers having same
interface type. Fault tolerance.
– Load balancing
– Servers can specify list of clients authorized to
use its services.
Disadvantages
– Overhead in binding clients to servers
– Binding agent centralized entity
Binding Time
When to bind client with server?
Compile Time
– Server’s network address can be compiled into the client
code and then found by looking up the server’s name in a
file i.e. specify server name in program itself.
– Inflexible – server moves, server is replicated, interface
changes then recompile client programs..
Link Time
– A client makes an import request to Binding Agent before
making a call.
– The Binding Agent binds Client and Server by returning
server’s handle to the client.
Call Time
– A client is bound to a server , when it calls the server for
the first time during its execution.
– Uses indirect call method.
Binding by Indirect Call
1. Client process passes server’s interface name & arguments to
2.
3.
4.
5.
binding agent
Binding agent sends an RPC call message to server including
client’s parameters
Server returns result to binding agent
Binding agent returns result to client with server’s handle
Client calls server directly subsequently.
Binding agent
2
1
4
3
Client process
Server process
5
Changing Bindings
– Can binding change during execution?
– Binding is altered by concerned server, it
ensures that any state data held by server is no
longer needed or can be duplicated in the
replacement server. Ex. State of open files
transferred from old to new file server.
Multiple Simultaneous Binding
– Can client bind with multiple servers that provide
same service?
– Client can be bound simultaneously to all or
multiple servers of the same type. Ex. Client
updates file replicated at many nodes.
– Client uses multicast communication.
RPC Semantics in the Presence of
Failures
The client is unable to locate the server
The request message from the client to server is
lost
The reply message from the server is lost
The server crashes after sending the reply
The client crashes after sending a request
Exception Handling
Define an exception condition for each possible
error type. On occurrence of exception, exception
handling procedure is called & executed
automatically in client’s environment.
Use conventional operating system method for
exception handling. Return a well known value to
process, making a system call to indicate failure &
report type of error by storing a suitable value in a
variable in environment of calling program.
Exception Handling
Client is Unable to Locate Server/
Can be used with those programming languages
that provide exception handling like ADA
Causes: server down, different version of server
…
Fixes
– Return -1 to indicate failure (in Unix use errno to
indicate failure type)
• What if -1 is a legal return value?
– Use exceptions
• Transparency is lost
Exception Handling
Lost Request Message
Easiest to deal with
Just retransmit the message!
If multiple messages are lost then
– “client is unable to locate server” error
Security
Authentication
Data encryption
Some implementations of RPCs include facilities
for client and server authentication and for
providing encryption based security for calls
Callback RPC
• Facilitates peer-to-peer paradigm by allowing process to be
both client and a server
• Server may make several callbacks to the client before
returning the result of the initial call to the client process.
Client
Server
Call (parameter list)
Start procedure execution
Stop procedure execution
temporarily
Process callback request
and send reply
Reply (result of callback)
Resume procedure
execution
Procedure execution ends
Essentials of Callback RPC
• Providing the server with the client’s handle so it can call
client back
• The client process uses a transient program number for
the callback service and registers it with Binding Agent,
which is then sent as part of RPC request to the server.
• To make a callback RPC , the server initiates a normal
RPC request to the client using the given program
number.
• Making the client process wait for the callback RPC.
• Make a call to svc-routine, which waits for server request
& then dispatches request to appropriate procedure.
• Handling call back deadlocks.
• A callback deadlock can occur due to the
interdependencies of processes.
P1
R21
P2
R13
R32
P3
Broadcast RPC
A client’s request is broadcasted on the network
and is processed by all the servers that have the
concerned procedure for processing that request.
The client waits for & receives many replies
depending on degree of reliability desired.
– Client uses special broadcast primitive.
Request sent to binding agent, which forwards
request to all servers registered with it.
– To declare broadcast ports. Client of broadcast
RPC obtains a binding for a broadcast port &
then broadcasts RPC message by sending
RPC message to this port.
Client can retransmit request using back-off
algorithm
Batch-Mode RPC
Used to queue separate requests in a transmission buffer on
the client side and then send them over the network in one
batch to the server.
Reduces overhead of sending single RPC.
Applications requiring higher call rates(50 -100 calls per sec)
become feasible with the use of batch-mode RPC.
Used when client has many RPC requests to send to a
server & client does not need any reply for a sequence of
requests.
Queue of requests flushed when :– A predetermined interval elapses.
– A predetermined number of request have been queued.
– Amount of batched data exceeds the buffer size.
– A call is made to one of the server’s procedures for
which a result is expected.
RPC in Heterogeneous
Environment
To design RPC system for heterogeneous
environment, delay decisions regarding Data
Representation, Transport Protocol & Control
Protocol until bind time.
Binding
mechanism
determines
correct
representation & protocol to be used between a
specific client & server & returns correct procedure
to stubs as result parameters of binding call.
Binding mechanism details are transparent to
users.
Monolithic vs. Micro Kernel
Monolithic kernel
– Kernel where the entire operating system is working in the
kernel space and alone as supervisor mode.
Micro kernel
– Kernel is reduced to contain minimal facilities necessary,
and the other system services reside in user space in form
of normal processes (as so called servers). Because the
servers do not run in kernel space anymore, so called
"context switches" are needed, to allow user processes to
enter privileged mode (and to exit again).
– Each server forms a component of operating system, exists
in its own protection domain, but all live within a single or
different address space (domain).
– Various components have to use some form of IPC to
communicate with each other.
– Simple & flexible.
Monolithic kernel vs. Micro kernel
Lightweight RPC
In microkernel approach , the communication traffic in OS
are of two types:
– Cross domain – communication between domains on the
same machine
– Cross machine - communication between domains
located on separate machines.
Lightweight RPC is used for cross- domain communications.
In cross domain communication small-simple parameters are
involved, overhead for the heavyweight machinery (message
buffer, marshaling, message transfer, access validation,
scheduling, dispatch, etc) is still paid.
Techniques used by LRPC
Simple Control Transfer - use the same thread
Simple Data Transfer - use shared argument stack
Simple Stubs - optimize for local transfer
Design for Concurrency - avoid shared data
structures
Simple Control Transfer
Uses special thread scheduling (Handoff scheduling – After
sending a message to another thread, the sending thread
gives up CPU & requests that the receiving thread be allowed
to run next.) for direct switch from the client thread to the
server thread of an LRPC.
When a client call a server’s procedure , it provide the server
with an argument stack and its own thread of execution.
The call causes trap to the kernel.
The kernel validates the caller, create a call linkage, and
dispatches the client’s thread directly to the server domain ,
causing the server to start executing.
After execution , control and results return through the kernel
back to the point of client’s call.
Simple Data Transfer
RPC requires data to be copied four times.
user-stub -> RPC message -> kernel -> RPC message ->
server-stub
LRPC requires data to be copied only once:
– From client stub’s stack to shared A-stack (preallocated
shared argument stack) from where server procedure can
access
Simple Stubs
LRPC uses a simple model of control and data transfer, facilitating the
generation of highly optimized stubs.
A three layered communication protocol is defined for each procedure
in an LPRC interface:
– End to end
– Stub to stub
– Domain to domain
Stubs blur boundaries between protocol layers to reduce the cost of
crossing them
On transferring control, kernel associates execution stacks with initial
call frame expected by called server’s procedure & directly invokes
corresponding entry in server’s domain. No intermediate message
examination or dispatching is done & server stub starts executing
procedure by directly branching to procedure’s first instruction.
A simple LRPC needs only one formal procedure call (into client stub)
and two returns (one out of server procedure and one out of client
stub)
Design for Concurrency
If the node of the client processes of an LRPC has
multiple processors with shared memory , special
mechanism are use to achieve –
Higher throughtput by minimizing the use of shared
data structure on critical domain transfer path.
Lower call latency by reducing context switching
overhead by caching domains on idle processors.
Optimization for Better
Performance
Concurrent access to multiple
servers
Use of threads in implementation of a client process where
each thread can independently make remote procedure calls
to different servers.
Call Buffering approach
– Client & Server interact via call buffer server
Early reply approach
– Call split into two separate RPC calls, one passing the
parameter to the server & other requesting the result
– In reply to the first call , server returns a tag that is sent
back with the second call to match the call with the result.
– The client decides the time delay between the two calls
and carries out other activities during this period.
Early Reply Approach
Client
Server
Call procedure (parameter)
Reply ( tag)
Return ( tag)
Execute procedure
Store (result)
Carry out other
activities
Request result (tag)
Return( result )
Reply ( result)
Servers Serving Multiple Requests Simultaneously
– Multiple threaded server with dynamic threads
creation facility to allow server to accept &
process other requests, while waiting for
completion of some operation
Reducing Per call Workload of Servers
– Use stateless servers & let clients keep track of
progression of their requests sent to servers
Reply Caching of Idempotent Remote Procedures
– Reply cache can also be associated with
idempotent remote procedures for improving a
server’s performance when it is heavily loaded.
Proper Selection of Timeout Values
– Depending on factors like server load, network
routing, network congestion. Can use back-off
strategy of exponentially increasing timeout
values.
Proper Design of RPC Protocol Specification
– Aim at minimizing amount of data to be sent &
its frequency.
SUN RPC
Stub Generation
– Automatic stub generation approach via IDL
called RPC Language (RPCL).
– Interface definition contains a program number,
version number of service, procedures
supported by service (Read, Write), input &
output parameters along with their types for
each procedure & the supporting type
definitions.
Interface definition generates:– Header file that contains definitions of common constants
& types defined in interface definition file
– An XDR (External Data Representation) file that contains
XDR marshalling/ unmarshalling procedures.
– Client stub file that contains one stub procedure for each
procedure defined in interface definition file.
– Server stub file that contains main routine (creates
transport handles & registers the service), dispatch routine
(dispatches remote procedure calls to appropriate
procedures) & one stub procedure for each procedure
defined in interface definition file.
Procedure Parameters
– Remote Procedure can accept only one
argument & return only one result. Multiple
parameters must be made components of a
single structure.
Marshalling Arguments & Results
– Data structures converted to XDR
Client Server Binding
– Each node has local binding agent called
portmapper that maintains database of mapping
of all local services. Client must specify host
name of server when it imports a service
interface. No location transparency.
Call Semantics
– At-least once semantics
Security
– No authentication
– Unix Style – User authenticated by its uid & gid.
– Data Encryption Standard where each user has
a globally unique name – ‘netname’
Special types of RPCs
– Supports asynchronous RPC, callback RPC,
broadcast RPC, batch mode RPC.
Critiques of SUN RPC
Lacks location transparency
Allows single argument & single result
Not transport independent. Limited to TCP or UDP.
Supports only at-least once semantics
Does not have network-wide client server binding
service
No integrated facility for threads.
DCE RPC
Automatic stub generation
– DCE RPC IDL allows completely general
specification of procedure arguments & results
– IDL compiler generates client & server stubs & a
header file.
At most once call semantics
Networkwide binding service for client-binding.
Uses Cell Directory Service.
Provide broadcast service