Request/Reply Communication

1. Request/Reply Communication Yiwei Wu

2. Outline • Introduction • What is RPC? • How it works? • RPC Models • Transparency Issues • Implementation • XML-RPC • Reference

3. Introduction [1,2,4,7] • Request/Reply Communication • The Request/Reply (R/R) communications method is a very common technique for one application to request the services of another. • Most widely used request/reply communication model is Remote Procedure Call (RPC) • It is used both by operating systems and applications • NFS is implemented as a set of RPCs • DCOM, CORBA, Java RMI, XML-RPC, etc., are all basically just RPC

4. What Is RPC [3] • It is based on extending the notion of conventional, or local procedure calling, so that the called procedure need not exist in the same address space as the calling procedure. • By using RPC, programmers of distributed applications avoid the details of the interface with the network. The transport independence of RPC isolates the application from the physical and logical elements of the data communications mechanism and allows the application to use a variety of transports.

5. How it works [3] • The client makes a procedure call that sends a request to the server and waits. The thread is blocked from processing until either a reply is received, or it times out. • When the request arrives, the server calls a dispatch routine that performs the requested service, and sends the reply to the client.

6. RPC Models [4] • There are several variations on the standard RPC “synchronous request/response” model • Each model provides greater flexibility, at the cost of less transparency • Certain RPC toolkits support all the different models • E.g. ONC RPC

7. RPC Models – Cont’d

8. RPC Models – Cont’d

9. Transparency Issues [4,5,6] • RPC has a number of limitations that must be understood to use the model effectively • Most of the limitations center around transparency • Transforming a simple local procedure call into system calls, data conversions, and network communications increases the chance of something going wrong • i.e., it reduces the transparency of distribution

10. Transparency Issues – Cont’d • Key Aspects of RPC Transparency • Parameter passing • Data representation • Binding • Transport protocol • Exception handling • Call semantics • Security • Performance

11. Parameter Passing [4,5,6] • Functions in an application that runs in a single process may collaborate via parameters and/or global variables • Functions in an application that runs in multiple processes on the same host may collaborate via message passing and/or non-distributed shared memory • However, passing parameters is typically the only way that RPC-based clients and servers share information

12. Parameter Passing – Cont’d • Parameters that are passed by value are fairly simple to handle • The client stub copies the value from the client and packages into a network message • Parameters passed by reference are much harder • e.g., in C when the address of a variable is passed • Or more generally, handling pointer-based data structures • e.g., pointers, lists, trees, stacks, graphs, etc.

13. Parameter Passing – Cont’d • Typical solutions include: • Have the RPC protocol only allow the client to pass arguments by value • Use a presentation data format where the user specially defines what the input arguments are and what the return values are • e.g., Sun's XDR routines • RPC facilities typically provide an “interface definition language" to handle this • e.g., CORBA or DCE IDL

14. Data Representation [4] • RPC client and server may have different hardware architectures and therefore may have different data representations (i.e., the method used to store data). • RPC systems intended for heterogeneous environments must be sensitive to byte ordering differences • They typically provide tools for automatically performing data conversion (e.g., rpcgen or idl)

15. Data Representation – Cont’d • Examples: • Sun RPC (XDR) • Imposes “canonical" big-endian byte-ordering • Minimum size of any field is 32 bits • Xerox Courier • Uses big-endian • Minimum size of any field is 16 bits • DCE RPC (NDR) • Supports multiple presentation layer formats • Allows the sender to use its own internal format, if it is supported • The receiver then converts this to the appropriate format, if different from the sender's format

16. Binding [4] • Binding is the process of connecting the client to the server • The server, when it starts up, exports its interface • Identifies itself to a network name server • Tells RPC runtime its alive and ready to accept calls • The client, before issuing any calls, imports the server • RPC runtime uses the name server to find the location of a server and establish a connection • The import and export operations are explicit in the server and client programs • Breakdown of transparency

17. Transport Protocol [4,6] • Some RPC implementations use only a single transport layer protocol • Others allow protocol section either implicitly or explicitly • Some examples: • Sun RPC • Earlier versions support only UDP, TCP • Recent versions are “transport independent" • DCE RPC • Runs over many, many protocol stacks • And other mechanisms that aren't stacks • e.g., shared memory • Xerox Courier • SPP

18. Exception Handling [4] • With a local procedure call there are a limited number of things that can go wrong, both with the call/return sequence and with the operations • e.g., invalid memory reference, divide by zero, etc. • With RPC, the possibility of something going wrong increases, e.g., • The actual remote server procedure itself generate an error • The client stub or server stub can encounter network problems or machine crashes • Two types of error codes are necessary to handle two types of problems • Communication infrastructure failures • Service failures • Another exception condition is a request by the client to stop the server during a computation

19. Call Semantics [4] • When a local procedure is called, there is never any question as to how many times the procedure executed • With a remote procedure, however, if you do not get a response after a certain interval, clients may not know how many times the remote procedure was executed

20. Call Semantics – Cont’d • There are three different forms of RPC call semantics: • Exactly once (same as local IPC) • Hard/impossible to achieve, because of server crashes or network failures • At most once • If normal return to caller occurs, the remote procedure was executed one time • If an error return is made, it is uncertain if remote procedure was executed one time or not at all • At least once • Typical for idempotent procedures, client stub keeps retransmitting its request until a valid response arrives • If client must send its request more than once, there is a possibility that the remote procedure was executed more than once

21. Security [4] • Typically, applications making local procedure calls do not have to worry about maintaining the integrity or security of the caller/callee • i.e., calls are typically made in the same address space • Remote security is handled via distributed authentication protocols • e.g., request/reply messages have not been tampered with (integrity), their contents are not revealed ( confidentiality) , and the same message has not appeared more than once ( originality )

22. Performance [4] • Usually the performance loss from using RPC is an order of magnitude or more, compared with making a local procedure call due to • Protocol processing • Context switching • Data copying • Network latency • Congestion

23. Performance – Cont’d • Another important aspect of performance is how the server handles multiple simultaneous requests from clients • Iterative -- server handles in the same process • May reduce throughput and increase latency • Concurrent -- server forks a new process or thread to handle each request • May require subtle synchronization, programming, and debugging techniques to work successfully • Thread solutions may be non-portable

24. Implementation – XML-RPC [7,8,9] • XML-RPC is a simple, portable way to make remote procedure calls over HTTP. • It can be used with Perl, Java, Python, C, C++, PHP and many other programming languages. • Implementations are available for Unix, Windows and the Macintosh.

25. XML-RPC [8]

26. XML-RPC [8] • XML-RPC call is conducted between two parties: • A client to send RPC request • A server to process RPC request and send back the return value to the client • Server’s address is in a standard URL • The data is composed by a HTTP header and a XML body

27. XML-RPC [7] An example of a typical XML-RPC request would be: <?xml version="1.0"?> <methodCall> <methodName>examples.getStateName</methodName> <params> <param> <value><i4>40</i4></value> </param> </params> </methodCall>

28. XML-RPC [7] An example of a typical XML-RPC response would be: <?xml version="1.0"?> <methodResponse> <params> <param> <value><string>South Dakota</string></value> </param> </params> </methodResponse>

29. Reference • Abraham Silberschatz, Peter B. Galvin, Greg Gagne, “Operation System Concepts (6th)”, John Wiley & Sons, Inc. • Randy chow, Theodore Johnson, “Distributed operating system and algorithms” • http://www.cs.cf.ac.uk/Dave/C/node33.html • Douglas C. Schmidt, “Overview of Remote Procedure Calls (RPC)”, Washington University, St. Louis, www.cs.wustl.edu/~schmidt/PDF/rpc4.pdf • http://msdn.microsoft.com/en-us/library/aa378651(VS.85).aspx • http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/ad/c0010962.htm • http://en.wikipedia.org/wiki/XML-RPC • http://www.xmlrpc.com/ • http://tldp.org/HOWTO/XML-RPC-HOWTO/xmlrpc-howto-intro.html

30. Thank You