Understanding Distributed Systems: RPC and Middleware Communication

Distributed Systems – Remote Procedure Calls Prof. Leonardo Mostarda University of Camerino Prof. Leonardo Mostarda-- Camerino,

Last Lecture • Client anatomy • Server Anatomy • Iterative and concurrent servers • Stateful and stateless servers • Server cluster organisation • Distributed servers and IPv6

Outline OSI model Middleware definition Types of Communication Remote Procedure Calls

Learning outcomes Understand the OSI model Understand and discuss different types of communication Understand and discuss the RPC Understand and discuss the main challenges when we need to implement the RPC

Layered Protocols (1) • Due to the absence of shared memory all communication in distributed systems is based on sending and receiving (low level) messages. • Agreements are needed at a variety of levels on how information is to be expressed and processed. • OSI provides a reference model to describe protocols

Layered Protocols (2) • A typical message as it appears on the network.

Middleware Protocols • Middleware is an application that logically lives (mostly) in the application layer, but which contains many general-purpose protocols. • Middleware general services • Authentication, authorisation • distributed commit protocols, fault tollerance • A middleware supports high-level communication services (transparency)

Types of Communication • Various alternatives in communication can be offered by a middleware • Persistent – the middleware stores the message until is delivered to the receiver (e.g., email) • Transient – a message is stored by the communication system only as long as the sending and receiving application are executing (e.g., transport level communication) • Besides being persistent or transient, communication can also be asynchronous or synchronous.

Conventional Procedure Call • Send and receive do not conceal communication at all • In 1984 Birrell and Nelson allowed programs to call procedures located on other machines • Suppose that A calls a procedure on machine B • The calling process on A is suspended • Execution of the called procedure takes place on B • No message passing at all is visible to the programmer. • This is known as Remote Procedure Call (RPC). • Some problems need to be faced • The calling and called procedures run on different machines, • They execute in different address spaces, • Parameters and results must be passed (different hardware/software)

Conventional Procedure Call • To understand RPC we need to fully understand how a conventional (i.e., single machine) procedure call works. • E.g. count = read(fd,buf,nbytes) • fd is an int (the file), buf is an array and nbytes an int (how many bytes to read) • Parameters can be call-by-value or call-by-reference • nbytes is by value while buf by reference

Client and Server Stubs • In RPC the calling procedure should not be aware that the called procedure is executing on a different machine. • When I read from the local file system the read routine is extracted from the library. It is a short procedure, which calls an equivalent read system call. • In RPC a different version of read (client stub) is put into the library. This sends a message instead of getting data from the local OS. • At the server side the message is passed to a server stub that transforms requests into local procedure calls • The server stub will replay the result back to the client stub

Remote Procedure Calls (1) • A remote procedure call occurs in the following steps: • The client procedure calls the client stub in the normal way. • The client stub builds a message and calls the local operating system. • The client’s OS sends the message to the remote OS. • The remote OS gives the message to the server stub. • The server stub unpacks the parameters and calls the server. Continued …

Remote Procedure Calls (2) • A remote procedure call occurs in the following steps (continued): • The server does the work and returns the result to the stub. • The server stub packs it in a message and calls its local OS. • The server’s OS sends the message to the client’s OS. • The client’s OS gives the message to the client stub. • The stub unpacks the result and returns to the client.

Passing Value Parameters (1) • The function of the client stub is to take the parameters, pack them into a message, and send them to the server stub (i.e., marshaling). • Several problems need to be faced • different data representation • EBCDIC character code and ASCII code • one's complement versus two's complement • endianness

Passing Value Parameters (2) • endianness: • (a) The messages on the Pentium, i.e., 5 and Jill • (b) The messages after receipt on the SPARC. • (c) The messages after being inverted (the string did not need to be inverted).

Parameter Specification and Stub Generation • How are pointers, or in general, references passed? • A pointer is meaningful only within the address space of the process in which it is being used. • What is the solution? • If we have an array then the client stub must copy the values of the array and pass them to the server stub • The server stub processes the array and sends back the modified array to the client stub. • The reference can be related to a complicated data structure

Parameter Specification and Stub Generation • Hiding a remote procedure call requires that • the caller and the callee agree on the format of the messages • they follow the same steps when it comes to exchange complex data structures • In the example below • a character is in the rightmost byte of a word • a float as a whole word • an array is preceded by a word giving the length,

Question • WHAT IS JSON? • SOAP (xml)? Prof. Leonardo Mostarda-- Camerino,

Interfaces Once the RPC protocol has been fully defined, the client and server stubs need to be implemented. Stubs for the same protocol but different procedures normally differ only in their interface to the applications. An interface is a collection of procedures. Interfaces are often specified by means of an Interface Definition Language (IDL). An interface specified in such an IDL is then subsequently compiled into a client stub and a server stub

Corba interface module Calc{ interface Calculator{ //User-defined exception exception MyException{}; //synchronous method float calculate(in float val1, in float val2, in char operator) raises (MyException); //asynchronous method onewayvoid set_value(in long val); }; };

Asynchronous RPC (1) • The interaction between client and server in a traditional RPC is synchronous. • In some case there is not result to be returned • transfer the balance, start a server

Asynchronous RPC (2) • RPC systems may provide facilities for what are called asynchronous RPCs • In asynchronous RPC a client immediately continues after issuing the RPC request. • The server immediately sends a reply back to the client the moment the RPC request is received, after which the server calls the requested procedure.

Asynchronous RPC (3) • Combining two asynchronous RPCs is some- times also referred to as a deferred synchronous RPC. • For instance the client may not be ready to process the answer

Asynchronous RPC It should be noted that variants of asynchronous RPCs exist. In One-way RPC the client does not wait for the acknowledgment from the server. The problem with this approach is that when reliability is not guaranteed, the client cannot know for sure whether or not its request will be processed.

summary OSI model Middleware definition Types of Communication Remote Procedure Calls

Understanding Distributed Systems: RPC and Middleware Communication