Transcript Remote Procedure Calls (RPC) and Distributed Objects G53ACC Chris Greenhalgh

Remote Procedure Calls (RPC) and
Distributed Objects
G53ACC
Chris Greenhalgh
1
Contents





Local procedure calls
Remote Procedure Call Model
Implementation Issues
– Transparency
– Binding
– Heterogeneity
– Concurrency
Making a Remote Procedure Call
– Stubless RPC
Distributed Objects
2
Books


Comer (4th ed) Chapter 38
Farley Chapter 3
3
Remote Procedure Calls




High level representation of Inter Process
Communication
– To transfer information
– To invoke an action in a remote process
Natural fit with client-server approach
Uses the normal procedure call metaphor and
programming style
Calls a procedure in another process
4
A “C” function call
(cf. Java static [class] method invocation)
int main()
{
int a=10;
int b=20;
2
int result;
1
result=add_numbers(a,b)
3
int add_numbers
(int a, int b)
{
return a+b;
}
4
}
Process X
5
What is a procedure call?



A general abstraction mechanism in imperative
programming languages
Parameterised “language extension”
Defined by an interface which specifies:
– the name of the operation
– the arguments to be passed

In some systems their direction, e.g. in/out/inout
– In is typically the default and/or only option (e.g. RMI)
– the type of results to be returned
6
The procedure call interface
Caller
example (x1,...,xn);
tr example(t1,...,tn)
Interface
Callee
example (y1,...,yn)
{
...
}
A procedure call must specify the argument and return types.
A remote procedure call must also specify which process to
locate the procedure in.
7
Making a local procedure
(or method) call…

A local procedure call:
– Copies the arguments onto the stack

(or “invocation record”)
– Allocates space for the return results
– Calls the procedure:
Preserves the address of the next instruction on the
stack
 Sets the program counter to the start of the called
function…

8
Making a local procedure call (2)

Called function starts to execute:
– Access arguments according to their position on the
stack


Has access to the same stack/invocation record
– Copies a return value into registers or onto the stack
– Restores the program counter to the value placed on the
stack by the caller…
Which resumes execution:
– Collects result from the stack
– Tidies up stack
9
A remote procedure call
int main()
{
int a=10;
int b=20;
2
int result;
1
result=add_numbers(a,b)
3
int add_numbers
(int a, int b)
{
return a+b;
}
4
}
Process X
Process Y
10
RPC Interface




Flows 1 and 3 are identical in both cases
– but each must be a different thread/process
Flow 2: call jumps from process X to Y
Flow 4: return jumps from process Y to X
=> Corresponds to two network messages
(2 and 4) plus control over execution
11
Local procedure call structure
Process/Application A
Caller
procedure
call interface
Callee
12
RPC version
Process/Application B
Process/Application A
Caller
Identical
procedure
call interface
RPC support
networking
Callee
RPC support
Request
Response
networking
Remote Procedure
“middleware”
Call standard(?) protocol
(typically over a TCP/IP connection)
13
Implementation Issues




Transparency
Binding
Heterogeneity
Concurrency
14
Implementation Issues 1:
Transparency

Def.
“Hiding” from the programmer whether a
particular procedure call is local or remote, or
which machine it runs on.
– Does/should the programmer “care” whether a
call was local or remote?
– Is it even possible to discover this?
15
Transparency

Pro:
No “special”/extra knowledge or information
required to
– Write a distributed application
– Understand a distributed program
16
Transparency

But…
– More things can go wrong in the remote case:
Partial failure: server – no answer?
 Partial failure: client – not worth continuing?
 Network failure: cannot communicate request and/or
response

– In general the program may need to deal with
these…
17
Transparency

Ideal?!
– Make it as much like a local procedure as
possible
– Minimise the situations in which extra
knowledge is required
– Provide facilities for programmer to access
“hidden” details if required

[Forward reference: Java RMI remote methods
throw RemoteException]
18
Achieving transparency

“Stub” code on client
– Generated by RPC tools
– Has same interface as remote procedure
–  called in exactly the same way
Same name
 Same arguments on stack
 Same return type

19
Achieving transparency

Similar “Stub” or “skeleton” code on server
– Also generated by RPC tools
– Calls the remote procedure body in the same
way as a normal procedure call
Same name
 Same arguments on stack
 Same return type

20
Other Unavoidable Differences

No shared memory between caller and callee
– Arguments and results are copied across the network
– So changes made to arguments in callee are not visible
to caller

Unless RPC system supports in/out & out arguments, which
are copied back to the callee [not JavaRMI]
– Result object cannot be a direct reference to an
argument – will be a copy
– Methods are invoked on the local copy


[unless they are themselves distribution/remote objects]
Binding must be specified – see next issue
21
Implementation Issues 2:
Binding


A local procedure call is satisfied in the local
process:
– linker matches procedure names
– fills in process-local address of procedure
An RPC allows us to call a procedure in another
process:
– How is an appropriate remote procedure
located?
– How do we specify (i.e. name) it?
– How do we communicate with it at the network
layer?
22
Binding



Option 1: use some configuration option or
additional support API to specify the remote
procedure
– Con: extra API, different to local case
Option 2: change the interface to include extra
information
– Con: different interface to local case
But object-oriented method invocations already
have an explicit target!
23
Distributed Objects


Remote Prodedure Call becomes
Remote Method Invocation
– i.e. methods can be invoked on objects which are
[ultimately] in another process.
Access and location transparency:
just another method invocation, but…
– Local object references are ultimately obtained by
instantiating an object (or loading a class) in the local
process.
– Remote object references are obtained from the
distributed object system itself.
– More things can still go wrong (see “transparency”)
24
Implementation Issues 3:
Heterogeneity

Def.
Allowing RPCs/RMIs between processes on
different machines
– different operating systems
– different data representation
little endian vs big endian representations
 integer and other type sizes and representations
 character sets

25
Heterogeneity:
Specifying the Interface

For describing the data structures (requests,
responses, arguments, results) being passed in an
RPC we can use either:
– a platform and programming languageindependent specification language, e.g.
OSI has ASN.1
 Internet (e.g. NFS) has XDR
 OMG CORBA has (an) IDL
 COM/DCOM IDL

– a particular programming language, e.g.

Java for RMI
26
Heterogeneity



The interface definition (and/or data representation)
language allows us to:
– translate a language and platform specific data structure
into a standard sequence of bytes (“marshall”)
– translate those bytes back into an equivalent data
structure (at the other end) (“unmarshall”)
Byte sequences are used in the lower layers of the
implementation and on the network
Native structures used in the higher layers – the actual
procedure/method call(s)
27
Implementation Issues 4:
Concurrency



A local procedure call has one thread (
– I.e. flow of control or virtual CPU
Threads are local to a single process
– (excepting some specialised distributed OSs)
So an RPC has (at least) two threads
– caller thread
– callee thread
28
Concurrency



Server side has a dispatcher
– with its own thread(s).
The dispatcher calls the appropriate function stub
with the data bytes
– gives the stub a thread of control to execute
Client thread may block waiting for results
– Synchronous (wait) vs. asynchronous (not)
29
Concurrency

Synchronous (blocking)
– Same “feel” as local procedure case
– Thread resources (memory) are idle
– Client may be left idle


(other threads with things to do?)
Asynchronous (non-blocking)
– Could be unreliable – never collects result
– Could be reliable


continue with other operations until the result is returned.
=> need some way to “rejoin” results (new API)
30
Making a Remote Procedure Call (cont.)
Start
Caller
Finish
Callee
10
1
specific
generic
Client
Stub
2
5
6
9
Server
Stub
7
Client
Comms
4
Server
Comms
8
3
Network
31
Request message

Contains:
– Byte sequence representations of arguments
– Byte sequence representation of method/procedure to
call
– [option] byte sequence representation of server object
identity
– [option] unique request identifier


To match responses and/or avoid duplicates
Also requires return information and error checking
– often part of networking support, e.g. TCP
33
Response message

Contains:
– Byte sequence representations of result (if any)

Or byte sequence representation of failure
description if unsuccessful
– [option] unique request identifier


To match with request and/or avoid duplicates
Also requires error checking
– often part of networking support, e.g. TCP
36
Making a remote procedure call (cont.)
Results in Client

Client comms function receives the response
– Standard networking
– Incoming response must be linked with calling
thread

E.g. by exclusive connection or explicit request ID
– returns the values to the waiting client stub (9)

Unmarshalling result
– which returns the value to the calling function
(10) which continues executing
37
If something goes wrong…

An error in the server
– Could be caught by the server stub (e.g. an
exception in the callee code)
An error message returned to the client
 Client stub reports this error to the caller

– E.g. throws an exception
– Could be detected by the client (e.g. a network
failure)

Client stub reports this error directly to the caller
– E.g. throws an exception
38
Stubless Remote Procedure Calls
Start
Caller
1
Dynamic
Invocation
API
2
Finish specific
reflective
10
generic 6
9
Callee
5
(Reflective?)
Generic
despatcher
7
Client
Comms
4
Server
Comms
8
3
Network
39
Stubless Remote Procedure Calls


No custom-generated interface-specific stub
– No custom-generated marshalling
Stubless client
– Caller directly constructs (using API) generic
RPC requests, that can be sent to any server
Still needs to know what the server will expect
 System may have a way to retrieve this information


Can make generic (universal) clients
– E.g. for testing, configuration and management
40
Stubless Remote Procedure Calls

Stubless server
– Generic stub translates request to local form
and invokes callee code directly
E.g. using language reflection facilities
 Less code generation
 Requires suitable language support and generic
marshalling framework

– Or generic stub delivers generic RPC requests
to generic callee code

E.g. for generic server that passes requests on to
another system, or for testing
41
Distributed Object Systems


Often called “middleware”, or
“run-time infrastructure”:
– Above the networking and OS, below the application
– Provide the “glue” to link objects in different
process/on different machines.
– May provide additional services and support.
Examples:
– Java RMI
– CORBA (platform independent standard)
– DCOM (Microsoft, Windows-specific)
– ANSAware, ...
42
Distributed Objects Systems (2)





Like RPCs (as already noted)
Relies on interface definitions
– e.g. Corba IDL, Java RMI interface bytecode
Defines what a client can ask
– client-middleware interface (method signatures)
– Supporting services (e.g. naming)
Defines what a server can do
– middleware-server interface
– Supporting services (e.g. persistence)
Middleware handles requests in generic, portable form
43