1. Topic 3: Remote Invocation Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine

2. 3.1 Client/Server Communication The client/server model underlies almost every distributed system. Hence it is important to understand the principles of client/server communication. Request protocol (R). Request-reply protocol (RR). Request reply acknowledgement protocol (RRA).

3. 3.1 Client/Server Communication  Request protocol (R) : The R protocol may be used when there is no value to be returned from the procedure and the client requires no confirmation that the procedure has been executed. The client may proceed immediately after the request message is sent as there is no need to wait for a reply message.

4. 3.1 Client/Server Communication  Request-reply protocol (RR) : The RR protocol is useful for most client-server exchanges because it is based on the request-reply protocol. Special acknowledgement messages are not required because a server’s reply message is regarded as an acknowledgement of the client’s request message. Similarly, a subsequent call from a client may be regarded as an acknowledgement of a server’s reply message.

5. 3.1 Client/Server Communication  Request-reply acknowledgement protocol (RRA) : The RRA protocol is based on the exchange of three messages: request-reply- acknowledge reply. The acknowledge reply message contains the requestid from the reply message being acknowledged. The arrival of a requestId in an acknowledgement message will be interpreted as acknowledging the receipt of all reply messages with lower requestIds, so the loss of an acknowledgement message is harmless. Although the exchange involves an additional message, it need not block the client as acknowledgement may be transmitted after the reply has been given to the client, but it does use processing and network resources.

6. 3.1 Client/Server Communication Request-reply protocols are usually: o Synchronous: as the client process blocks until a reply is received from the server process. o Reliable: as replies from the server process act as acknowledgment of receiption. A request-reply protocol is based on three main communication operations: o doOperation: used by clients to invoke remote operations. It contains a set of arguments required for the operation call. o getRequest: used by the server to get client’s service requests. o sendReply: used by the server to send reply messages back to the client.

7. 3.1 Client/Server Communication  Request-reply protocol (RR): When the client receives a reply, its original doOperation is unblocked and execution of the client process continues. The doOperation performs marshalling of the call’s arguments and unmarshalling of the result received. Marshalling is the process of taking of data items and transform them into a suitable form for transmission. Unmarshalling is the opposite process in which data items are transformed back to their original form on receiption. Marshalling and unmarshalling is usually carried out by a middleware without needing the application programmer to be involved in such processes.

8. 3.1 Client/Server Communication

10.  Request-reply message structure : The information to be transmitted in a request message or a reply message is shown in figure. The first field indicates whether the message is a Request or a Reply message. The second field, requestId, contains a message identifier (Int + port +IP). A doOperation in the client generates a requestId for each request message, and the server copies these IDs into the corresponding reply messages. The third field is a remote reference. The fourth field is an identifier for the operation to be invoked.

11. 3.1 Client/Server Communication  Failure model of the request-reply protocol: If the three primitives doOperation, getRequest and sendReply are implemented over UDP datagrams: They suffer from omission failures. Messages are not guaranteed to be delivered in sender order. Timeout (client) : doOperation uses a timeout when it is waiting to get the server’s reply message. The simplest option to the client indicate that doOperation has failed. Or request reply messages getting lost. Thus, the doOperation sends the request message repeatedly.

12. 3.1 Client/Server Communication  Failure model of the request-reply protocol: Discarding duplicate request messages (Server) : multiple request is retransmitted. usually, happen when server execution time take longer than doOperation timeout. This can lead to the server executing an operation more than once for the same request. Solution: the protocol is designed to recognize successive messages (from the same client) with the same request identifier and to filter out duplicates.

13. 3.1 Client/Server Communication  HTTP: an Example of a Request-Reply Protocol The HyperText Transfer Protocol (HTTP) enables clients’ web browsers to access services on the web. Web browsers make requests to web servers and receive replies from them. Web servers manage resources implemented in different ways: As data: e.g. HTML documents, images, applet classes. As programs: e.g. cgi, PHP and Java Servlets scripts. Clients specify a Uniform Resource Locator (URL) containing the DNS of the server host, possibly a port number and an identifier of a resource on the server. HTTP is a protocol that specifies the messages required in a request-reply communication including: Methods, their arguments and results. The rules of presenting such methods in the messages (marshalling).

14. 3.1 Client/Server Communication  HTTP: an Example of a Request-Reply Protocol Requests and replies are marshalled into messages as ASCI text strings. Resources implemented as data are provided using the Multipurpose Internet Mail Extensions (MIME) standard. MIME is a standard used to send data of multiple parts including text, images and sound. At the beginning of the message’s data part, a MIME type is specified so the receiver knows how to handle it. A MIME type specifies a type and subtype such as text/plain, text/html. Image/gif or image/jpeg.

15. 3.1 Client/Server Communication  Structure of a HTTP Interaction In the original HTTP protocol, each client-server interaction includes the following steps. The client makes a request. The server accepts a connection at the default port or at a port specified by the URL. The client sends a request message to the server. The Server sends a reply message to the client. The connection is closed.

16. 3.1 Client/Server Communication  Structure of a HTTP Interaction Thus, a new connection is established for each request-reply interaction. This can be expensive as it might cause: Overload at the server. Increases the traffic in the network as more messages are exchanged to establish connections. In HTTP version 1.1, this was modified by using persistent connections. A persistent connection remain open over a series of request- reply interactions.

17. 3.1 Client/Server Communication  HTTP Methods HTTP specifies a fixed set of methods that can be used to support all of its resources. Each HTTP user request specifies the name of a method to be applied to a resource and the URL of the resource. The methods include the following: GET: used to requests a resource whose URL is given as an argument. The resource can be data or a program. If data, the web server replies by providing the file containing that data (e.g. HTML static document). If a program, the web server runs the program and returns its output to the client (e.g. a PHP script). GET can also be used to send other parameters encoded in the URL, such as the content of a form.

18. 3.1 Client/Server Communication  HTTP Methods HEAD: identical to GET, but only returns information about the data rather than the data itself (e.g. type, size, etc.). POST: specifies the URL of a resource (e.g. a program) that can deal with the data supplied with the request. Data is provided with the request which is handled by a script such as a. PHP or Java servlet script. Other methods include PUT, DELETE, OPTIONS and TRACE.

19. 3.1 Client/Server Communication  HTTP Message Format Request Message Reply Message

20. 3.2 Remote Procedure Call  Introduction The remote procedure call (RPC) approach extends the common programming abstraction of the procedure call to distributed environments, allowing a calling process to call a procedure in a remote node as if it is local. This concept was first introduced by Birrell and Nelson [1984] and paved the way for many of the developments in distributed systems programming used today. By using RPC, the goal of making the programming of distributed systems look similar, if not identical, to conventional programming Can achieve a high level of distribution transparency by hiding important aspects of distribution, including the encoding and decoding of parameters and results, the passing of messages and the preserving of the required semantics for the procedure call. In RPC, procedures on remote machines can be called as if they are procedures in the local address space.

21. 3.2 Remote Procedure Call  Design issues for RPC We will discuss three main issues to understand the concept : the style of programming promoted by RPC programming with interfaces. the call semantics associated with RPC. the key issue of transparency and how it relates to remote procedure calls

22. 3.2 Remote Procedure Call  Design issues for RPC Programming with interfaces (basic concept): In the modern programming languages, Communication between modules can be by means of procedure calls between modules or by direct access to the variables in another module. By defining an explicit interface, the procedures and the variables can be accessed from other modules. Modules are implemented to hide all the information about them except that which is available through its interface. The implementation may be changed without affecting the users of the modules.

23. 3.2 Remote Procedure Call  Design issues for RPC Interfaces in distributed system: In a distributed program, the modules can run in separate processes. In the client-server model, each server provide a set of procedure to the clients. The term service interface is used to refer to the specification of the procedures offered by a server, defining the types of the arguments of each of the procedures. Benefit of using interfaces in DS: programmers are concerned only with the abstraction offered by the service interface. Programmers also do not need to know the programming language or underlying platform used to implement the service (potentially heterogamous). implementations can change as long as long as the interface (the external view) remains the same.

24. 3.2 Remote Procedure Call  Design issues for RPC Interfaces in distributed system: It is not possible for a client module running in one process to access the variables in a module in another process. The parameter-passing mechanisms used in local procedure calls (call by value and call by reference). This mechanisms is not suitable in distributed environment. Input parameters are passed to the remote server by sending the values of the arguments in the request message and then supplying them as arguments to the operation to be executed in the server. Output parameters are returned in the reply message and are used as the result of the call. In distributed environment, addresses cannot be passed as arguments or returned as results of calls to remote modules

25. 3.2 Remote Procedure Call  Design issues for RPC Interface definition languages (IDL): An RPC mechanism can be integrated with a particular programming language, using common notation for interfaces, allowing input and output parameters to be mapped onto the language’s normal use of parameters. This approach is useful when all the parts of a distributed application can be written in the same language. IDLs are designed to allow procedures implemented in different languages to invoke one another. An IDL provides a notation for defining interfaces for different programing languages. Sun XDR(External Data Representation) as an example of an IDL for RPC. CORBA IDL as an example of an IDL for RMI. the Web Services Description Language (WSDL ) for Web Services.

26. 3.2 Remote Procedure Call  Design issues for RPC Interface definition languages (IDL):

27. 3.2 Remote Procedure Call  Design issues for RPC call semantic: In the local procedure calls, the semantics are exactly once, meaning that every procedure is executed exactly once (except in the case of process failure). In the RPC invocation semantics are defined as follows. Maybe semantics: the remote procedure call may be executed once or not at all. At-least-once semantics: the invoker receives either a result, in which case the invoker knows that the procedure was executed at least once, or an exception informing it that no result was received. At-most-once semantics: the caller receives either a result, in which case the caller knows that the procedure was executed exactly once, or an exception informing it that no result was received, in which case the procedure will have been executed either once or not at all.

28. 3.2 Remote Procedure Call  Design issues for RPC

30. 3.2 Remote Procedure Call  Design issues for RPC Transparency: The originators of RPC, Birrell and Nelson [1984], aimed to make remote procedure calls as much like local procedure calls as possible, with no distinction in syntax between a local and a remote procedure call. All the necessary calls to marshalling and message-passing procedures were hidden from the programmer making the call. At least RPC should offer location and access transparency. What about failure handling? By using complete transparency the programmers couldn’t identify if the failure belongs to network or remote server process failure.

31. 3.2 Remote Procedure Call  Implementation of RPC call semantic: RPC is generally implemented over a request-reply protocol. RPC may be implemented to have one of the choices of invocation semantics. at-least-once or at-most-once is generally chosen. The software components required to implement RPC are shown in the next slide. Stub procedure: behaves like a local procedure to the client, but instead of executing the call, it marshals the procedure identifier and the arguments into a request message. communication module: to handle the request/reply that contains the procedure identifier and the arguments. Dispatcher: selects one of the server stub procedures according to the procedure identifier in the request message.

32. 3.2 Remote Procedure Call  Implementation of RPC

33. QUIZ Define with example the distributed system transparency?