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

2 Contents l Local procedure calls l Remote Procedure Call Model l Implementation Issues –Transparency –Binding –Heterogeneity –Concurrency l Making a Remote Procedure Call –Stubless RPC l Distributed Objects

3 Books l Comer (4 th ed) Chapter 38 l Farley Chapter 3

4 Remote Procedure Calls l High level representation of Inter Process Communication –To transfer information –To invoke an action in a remote process l Natural fit with client-server approach l Uses the normal procedure call metaphor and programming style l Calls a procedure in another process

5 A “C” function call (cf. Java static [class] method invocation) int main() { int a=10; int b=20; int result; result=add_numbers(a,b) } int add_numbers (int a, int b) { return a+b; } Process X 1

6 What is a procedure call? l A general abstraction mechanism in imperative programming languages l Parameterised “language extension” l Defined by an interface which specifies: –the name of the operation –the arguments to be passed l 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

7 The procedure call interface Caller example (x1,...,xn); 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. Interface tr example(t1,...,tn)

8 Making a local procedure (or method) call… l A local procedure call: –Copies the arguments onto the stack l (or “invocation record”) –Allocates space for the return results –Calls the procedure: l Preserves the address of the next instruction on the stack l Sets the program counter to the start of the called function…

9 Making a local procedure call (2) l Called function starts to execute: –Access arguments according to their position on the stack l 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… l Which resumes execution: –Collects result from the stack –Tidies up stack

10 A remote procedure call int main() { int a=10; int b=20; int result; result=add_numbers(a,b) } int add_numbers (int a, int b) { return a+b; } Process Y Process X 1

11 RPC Interface l Flows 1 and 3 are identical in both cases –but each must be a different thread/process l Flow 2: call jumps from process X to Y l Flow 4: return jumps from process Y to X l => Corresponds to two network messages (2 and 4) plus control over execution

12 Local procedure call structure Process/Application A procedure call interface Callee Caller

13 RPC version Callee Process/Application B Caller Process/Application A RPC support Remote Procedure Call standard(?) protocol (typically over a TCP/IP connection) Identical procedure call interface Request   Response networking RPC support networking “middleware”

14 Implementation Issues l Transparency l Binding l Heterogeneity l Concurrency

15 Implementation Issues 1: Transparency l 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?

16 Transparency l Pro: No “special”/extra knowledge or information required to –Write a distributed application –Understand a distributed program

17 Transparency l But… –More things can go wrong in the remote case: l Partial failure: server – no answer? l Partial failure: client – not worth continuing? l Network failure: cannot communicate request and/or response –In general the program may need to deal with these…

18 Transparency l 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 l [Forward reference: Java RMI remote methods throw RemoteException]

19 Achieving transparency l “Stub” code on client –Generated by RPC tools –Has same interface as remote procedure –  called in exactly the same way l Same name l Same arguments on stack l Same return type

20 Achieving transparency l 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 l Same name l Same arguments on stack l Same return type

21 Other Unavoidable Differences l 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 l 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 l [unless they are themselves distribution/remote objects] l Binding must be specified – see next issue

22 Implementation Issues 2: Binding l A local procedure call is satisfied in the local process: –linker matches procedure names –fills in process-local address of procedure l 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?

23 Binding l Option 1: use some configuration option or additional support API to specify the remote procedure –Con: extra API, different to local case l Option 2: change the interface to include extra information –Con: different interface to local case l But object-oriented method invocations already have an explicit target!

24 Distributed Objects l Remote Prodedure Call becomes Remote Method Invocation –i.e. methods can be invoked on objects which are [ultimately] in another process. l 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”)

25 Implementation Issues 3: Heterogeneity l Def. Allowing RPCs/RMIs between processes on different machines –different operating systems –different data representation l little endian vs big endian representations l integer and other type sizes and representations l character sets

26 Heterogeneity: Specifying the Interface l For describing the data structures (requests, responses, arguments, results) being passed in an RPC we can use either: –a platform and programming language- independent specification language, e.g. l OSI has ASN.1 l Internet (e.g. NFS) has XDR l OMG CORBA has (an) IDL l COM/DCOM IDL –a particular programming language, e.g. l Java for RMI

27 Heterogeneity l 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”) l Byte sequences are used in the lower layers of the implementation and on the network l Native structures used in the higher layers – the actual procedure/method call(s)

28 Implementation Issues 4: Concurrency l A local procedure call has one thread ( –I.e. flow of control or virtual CPU l Threads are local to a single process –(excepting some specialised distributed OSs) l So an RPC has (at least) two threads –caller thread –callee thread

29 Concurrency l Server side has a dispatcher –with its own thread(s). l The dispatcher calls the appropriate function stub with the data bytes –gives the stub a thread of control to execute l Client thread may block waiting for results –Synchronous (wait) vs. asynchronous (not)

30 Concurrency l Synchronous (blocking) –Same “feel” as local procedure case –Thread resources (memory) are idle –Client may be left idle l (other threads with things to do?) l Asynchronous (non-blocking) –Could be unreliable – never collects result –Could be reliable l continue with other operations until the result is returned. l => need some way to “rejoin” results (new API)

31 Making a Remote Procedure Call (cont.) Client Stub Client Comms 2 9 Callee 5 Server Stub 4 7 Server Comms 3 Network Caller Start 10 Finish generic specific

32 Making a remote procedure call (cont.) The Client Stub l The caller’s ancillary operations are gathered into a client stub (1) l The stub makes the required preparations and the passes the data to the processes’ communications function (2) –Marshalls native argument types into byte sequences l The comms. function passes a stream of bytes to the remote process, which is listening for them (3) –Uses standard networking facilities, e.g. TCP or UDP

33 Request message l 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 l To match responses and/or avoid duplicates l Also requires return information and error checking –often part of networking support, e.g. TCP

34 Making a remote procedure call (cont.) The Server Stub l Server comms. function listens for incoming communications (3) –Again using standard networking facilities l Collects the incoming data, derives the procedure being called, and passes the data to the stub for that procedure (4) –Unmarshalls transmitted bytes to native types for arguments l The stub then calls the actual procedure code with the received arguments (5) –Identified by e.g. name in received message

35 Making a remote procedure call (cont.) Results in Server l Procedure call results on the server side are returned to the server stub (6) l The server stub then passes the results to the server comms (7) –Marshalling result l which sends them to the client comms as a byte stream (8). –Standard networking

36 Response message l Contains: –Byte sequence representations of result (if any) l Or byte sequence representation of failure description if unsuccessful –[option] unique request identifier l To match with request and/or avoid duplicates l Also requires error checking –often part of networking support, e.g. TCP

37 Making a remote procedure call (cont.) Results in Client l Client comms function receives the response –Standard networking –Incoming response must be linked with calling thread l E.g. by exclusive connection or explicit request ID –returns the values to the waiting client stub (9) l Unmarshalling result –which returns the value to the calling function (10) which continues executing

38 If something goes wrong… l An error in the server –Could be caught by the server stub (e.g. an exception in the callee code) l An error message returned to the client l Client stub reports this error to the caller –E.g. throws an exception –Could be detected by the client (e.g. a network failure) l Client stub reports this error directly to the caller –E.g. throws an exception

39 Stubless Remote Procedure Calls Dynamic Invocation API Client Comms 2 9 Callee 5 (Reflective?) Generic despatcher 47 Server Comms 3 Network Caller Start 10 Finish generic specific reflective

40 Stubless Remote Procedure Calls l No custom-generated interface-specific stub –No custom-generated marshalling l Stubless client –Caller directly constructs (using API) generic RPC requests, that can be sent to any server l Still needs to know what the server will expect l System may have a way to retrieve this information l Can make generic (universal) clients –E.g. for testing, configuration and management

41 Stubless Remote Procedure Calls l Stubless server –Generic stub translates request to local form and invokes callee code directly l E.g. using language reflection facilities l Less code generation l Requires suitable language support and generic marshalling framework –Or generic stub delivers generic RPC requests to generic callee code l E.g. for generic server that passes requests on to another system, or for testing

42 Distributed Object Systems l 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. l Examples: –Java RMI –CORBA (platform independent standard) –DCOM (Microsoft, Windows-specific) –ANSAware,...

43 Distributed Objects Systems (2) l Like RPCs (as already noted) l Relies on interface definitions –e.g. Corba IDL, Java RMI interface bytecode l Defines what a client can ask –client-middleware interface (method signatures) –Supporting services (e.g. naming) l Defines what a server can do –middleware-server interface –Supporting services (e.g. persistence) l Middleware handles requests in generic, portable form