Request/Reply Communication

1. Request/Reply Communication Mary Hudachek-Buswell GSU CSC 8320, Section 4.2 Fall 2011

2. Outline of Background • Introduction • Request /Reply Communication • Remote Procedure Call (RPC) • RPC Operations • Parameter Passing • Data Conversion • Binding • RPC Compilation • RPC Errors and Failure • Exception • Failure Handling • RPC Security 2

3. Introduction– Request/Reply • Request/Reply Communication • Send a single block of data/packet, then wait for a reply before sending another packet • Request/Reply protocols include FTP, HTTP, SMTP, POP, IMAP, etc… • Remote Procedure Call (RPC); the Internet's most widely used request/reply communication model 3

4. Introduction– Request/Reply Communication Request Queue Requestor Replier Reply Queue 4

5. Introduction– Remote Procedure Call Apparent Flow Client Process Server Process Client (request initiated) Manager Procedures call return return call return call Interface Client Stub (pack request for transfer) Server Stub (unpack request ) return call call return call RPC Runtime Library RPC Runtime Library return Transport Network Messages 5 http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.progcomm%2Fdoc%2Fprogcomc%2Frpc_mod.

6. RPC Operations Parameter Passing - what data can be passed Data Conversion - how is the data represented Binding - locating server and registering the service RPC Compilation - origination of stub procedures and linking 6

7. RPC Operations - Parameter Passing • Single process: via parameters and/or global variables • Multiple processes on the same host: via message passing • Passing parameters is typically the only way that RPC-based clients and servers share information • Parameter marshaling: Rules for parameter passing and data/message conversion is the primary responsibility of Stub procedure • Parameter-passing modes: • IN: pass info from caller to receiver • OUT: receiver writes a value in the caller • IN/OUT: caller tells receiver value of variable, which may be updated by receiver 7

8. RPC Operations - Parameter Passing • Call-by-value: just copy data to network message where value passed to procedure is copied to local variable, client stub performs copy • Call-by-reference:pass pointer address and same memory location is referred to in passing, hard to implement in distributed systems with non-shared memory. • Call-by-copy/restore:combination of call-by-value and call-by-reference. Call-by-value at the entry of call and call-by-reference to the exit of the call • Call-by-name:requires dynamic run-time evaluation of symbolic expression. • Most RPC implementations assume that parameters are passed by call-by-value and call-by-copy/restore. 8

9. RPC Operations - Data Conversion • Three areas requiring conversion between data and message • Data typing • Data representation • Data transfer syntax • Incompatibility issues of data passed from local machine to remote machine • Different byte ordering • Different sizes of integers and other types • Different floating point representations • Different character sets • Alignment requirements 9

10. RPC Operations - Data Conversion • Needed standard encoding to enable communication between heterogeneous systems using symmetric conversion • ASN.1 (ISO Abstract Syntax Notation) • Most important developments in standards. • Used to define data structures. • Used for specifying formats of protocol data units in network communications. • Data types are checked during stub generation and compilation. • Sun’s RPC uses XDR (eXternal Data Representation) 10

11. RPC Operations - Data Conversion • For example: IP (headers) forced all to use ‘big endian’ byte ordering for 16 and 32 bit values • Most significant byte in low memory • Sparc, 680x0, MIPS, PowerPC G5 • x86/Pentiums use little endian big endian little endian Client data Server data • Symmetric • Conversion Convert data Convert data ntohl()… (network to host) htonl()… (host to network) 11

12. RPC Operations - Data Conversion • Network Data Representation (NDR) is used in the Distributed Computing Environment (DCE) • Uses asymmetric “receiver-makes-right” • Open Source Foundation’s Distributed Computing Environment RPC uses IDL (Interface Definition Language) big endian little endian Client data Server data • Asymmetric • Conversion Convert data 12

13. Binding is the process of connecting the client to the server Services are specified by a server interface with interface definition language such as XDR. RPC Operations - Binding 13

14. The server starts up Register its communication endpoint by sending a request (program, version number, port number) to the port mapper . Port mapper manages the mapping. Before RPC, client call RPC run-time library routine create, which contacts the port mapper to obtain a handle for accessing. Create message contains the server name, program, version number, transport protocol. Port mapper verifies the program and version numbers, returns the port number of the server to the client. Client builds a client handle for subsequent use in RPC. This establishes socket connections between clients and server. RPC Operations - Binding 14

15. RPC Operations - Binding Server machine address or handle to server Register service (if server is unknown) directory server port mapper 2. create 1. register 3. port # client server 4. handle 15

16. Compilation of RPC requires the followings: An interface specification file An RPC generator : input is the interface specification file and output is the client and server stub procedure source codes. A run-time library for supporting execution of an RPC, including support for binding, data conversion, and communication RPC Operations - Compilation 16

17. RPC Operations - Compilation Interface Specification File RPC Generator Client Code Client Stub Header File Server Stub Server Code Language Compiler Language Compiler Client Application Server Application 17

18. RPC Errors and Failure – Exception Handling • Exceptions are abnormal conditions raised by the execution of server stub and procedures. • Exceptions that occur in server application, server stub, and server run-time library (above the transport layer) are propagated to the client • If a server routine encounters an error that prevents it from executing the RPC, it raises an exception after cleaning up and before returning to the RPC run time, • Server routine doesn’t return a value to RPC that only the server routine recognizes as an error • Examples of exceptions: Overflow/underflow, protection violation 18

19. RPC Errors and Failure – Exception Handling • Exceptions must be reported to the clients. • Question: how the server report status information to clients? • A client may have to stop the execution of a server procedure. • Question: how does a client send control information to a server? • In local procedure call: global variables and signals. • In computer network, the exchange of control and status information must rely on a data channel. • In-band signaling, or out-band signaling (flag). • Separate channel (socket connection) – more flexible for RPC • It is implemented as part of the stub library support and should be transparent. 19

20. RPC Errors and Failure – Failure Handling • Problems caused by crashes of clients and servers, or the communication network. • Cannot locate the server • Nonexistent server, or outdated program • Handle like an exception. • Messages can be delayed or lost • Eventually detected by a time-out or by no response from the server • The messages can be retransmitted 20

21. RPC Errors and Failure – Failure Handling • Problem with Retransmission of requests. • Delay case: server gets multiple requests • Idempotent case: request executed multiple times with no change in result • Idempotent case of impossible (lock servers), each request has sequence number. • Typically RPC do not use sequence numbers – only requests-based. 21

22. RPC Errors and Failure – Failure Handling • Crash of a server • Client attempts to reestablish a connection, and retransmits its request. • If server not fail, but TCP connection fail: examine the cache table for duplicated message. • If server failed, then cache table lost. Then raise exception. • Three assumptions for RPC semantics in failures. • Server raise exception, client retries. At least once • Server raise exception, client give up immediately At most once • No error report from server, client resubmits until it gets or give up Maybe 22

23. RPC Errors and Failure – Failure Handling • Most desirable RPC semantics occur exactly once • But hard to implement. • Loss of cache table: at least once and log the cache table to storage. • Reload the cache table when server recovers. • Overhead since each service must be executed as a transaction at the server 23

24. RPC Errors and Failure – Failure Handling • Crash of a client process • Server has an orphan communication and its reply is undeliverable. • Orphan computation waste server resources, may confuse the client with invalid replies from previous connections. • How to eliminate orphan communication? But hard to implement • Client: On reboot, cleans up all previous requests. • Server: Occasionally locate owners of requests. • Expiration: Each remote operation is given a maximum lifetime. 24

25. RPC Errors and Failure – Failure Handling 25 http://www.cherrypy.org/chrome/common/2.2/docs/book/chunk/ch03.html

26. RPC Security • Security areas in RPC resulting from • RPC introduces vulnerability because it opens doors for attacks. • RPC is a cornerstone of client/server communication • Primary security issues • Authentication of processes. • Confidentiality of messages. • Access control authorization from client to server. 26

27. RPC Security • Authentication protocol for RPC should establish: • Mutual authentication. • Message integrity, confidentiality, and originality. • Design of a secure authentication protocol • How strong the security goals. • What possible attacks • Some inherent limitations of the system. • Short-term solution: additional security features. 27

28. RPC Security – Sun Secure RPC • Sun’s Secure RPC • Built into Sun’s basic RPC. • Assume a trusted Network Information Service (NIS), which keeps a database and secret keys. • The keys are for generating a true crypto graphical session key. • When user login, NIS gives the key. With user password, the key used to decrypt the secret key, discard password. • Passwords are not transmitted in the network. 28

29. RPC Security – Sun Secure RPC

30. RPC Security – Sun Secure RPC • Sun secure RPC – RPC message may contain more • Timestamp : check message expiration • Nonce : protect against the replay of a message • Message digest: detect any tampering. • Sun secure RPC is simple, using existing NIS. 30

31. Outline of RPC Current & Future • History • Examples of somewhat recent designs • GridRPC • ICE • Recent research activity • Multiple Grid • FlexRPC • SpartanRPC • S-RPC • Serial Multicast 31

32. History of RPC • 70s Remote Procedure Call (RPC) • 80s Communication protocol models focused on the network layer • Microsoft's Distributed Computing Environment (DCE) • Network File System (NFS) by Sun Microsystems • 90s Object RPC (ORPC) codified the mapping of a communication endpoint to a language-level object • DCOM distributed extension builds an ORPC)layer on top of DCE RPC (Microsoft) • Common Object Request Broker Architecture (CORBA) does the same on Unix systems • Any solution built on these protocols will be dependent on a single vendors implementation, • Both these protocols depend on a closely administered environment • Late in 90s Doors (Solaris) for UNIX operating system 32

33. History of RPC • 00s improved object and component • Java’s Remote Method Invocation (RMI) is their traditional method of performing remote communications and uses a non-standardized protocol • Microsoft Transaction Server (MTS) component-based transaction processing system • DDObjects for Borland Delphi and C++ Builder based on DCOM, RMI, Corba • Late 00s Grid computing is composed of many networked loosely coupled computers acting together to perform very large tasks. • GridRPC distributes individual applications and serves as a base for higher –level substrates such as distributed scientific components, Ninf and NetSolve • ICE (Internet Communications Engine) for grid computing 33 http://www.ibm.com/developerworks/webservices/library/

34. GridRPC • Grid computing distributes individual applications and serves as a base for higher–level substrates such as distributed scientific components, RPC much more complicated • Two different grid computing systems to look at: NetSolve and Ninf • Both support remote procedure calls (RPCs) on the Grid • Standardized at GridRPC • Standardizing only minimal set of APIs • Higher-level features can be built on top • Providing several reference implementations • Usage scenarios • Remote library calls for executing compute-intensive tasks • Executing large scale task-parallel processing 34

35. GridRPC Ninf-G2 • Implementation of GridRPC • Constructed on top of Globus, online grid computing • Globus is introduced in many sites • No more security halls are required in introducing Ninf-G2 • Ninfied applications can be executed on many sites • Globus provides primitive functions/tools for grid computing • Concentrating on the development of RPC specific functions • Easy to use other tools on Globus • Ninf-G2 hides complicated mechanisms of Globus • Grid applications/middleware can be easily constructed 35 http://www.globus.org/grid_software/computation/ninf-g.php

36. ICE (Internet Communications Engine) • ICE is object-oriented middleware providing RPC, grid computing, and publish/subscribe functionality. • Influenced by CORBA (Common Object Request Broker Architecture) in its design, and developed by ZeroC, Inc. • Supports C++, Java, .NET-languages, Objective-C, Python, PHP, and Ruby on most major operating systems. 36

37. ICE (Internet Communications Engine) 37 http://en.wikipedia.org/wiki/Internet_Communications_Engine

38. ICE • Ice middleware in the New Solar Telescope’s Telescope Control System, 2008 [5] • NST (new solar telescope) is an off-axis solar telescope with the world largest aperture. • Develop TCS (telescope control system) to control all aspects of the telescope • Ice advantages • Provides Simple ,fast and scalable communications. • Ice Embedded (Ice-E) supports Microsoft Windows Mobile operating system for handheld devices. • Source code of Ice is provided under the GNU (General Public License) • Continuously updated. 38

39. ICE • TCS Implementation (sample of RPC) • Star-like structure: all subsystems through HQ (headquarters). • Each subsystem acts as a server and a client. • Each subsystem use the same ICE interface. • Interface for every object includes seven operations; • Register, Unregister, SendError, SendCommand, RequestInformation, SendNotification, SendReply, Error • Subsystems can be started in any order, only need to register with HQ and IcePack registry. 39

40. New Research: Multiple Grid (2006) Integrating Computing Resources on Multiple Grid-enabled Job Scheduling Systems Through a Grid RPC System 2006 • Framework for parallel programming by RPC  • Bridge created for large scale computing resource pools managed by multiple grid enabled job scheduling systems • User can exploit remote servers, clusters, and computing resources on grid-enabled job scheduling systems located on different sites Nakajima, Y.; Sato, M.; Aida, Y.; Boku, T.; Cappello, F.; , "Integrating Computing Resources on Multiple Grid-enabled Job Scheduling Systems Through a Grid RPC System," Cluster Computing and the Grid, 2006. CCGRID 06. Sixth IEEE International Symposium on , vol.1, no., pp. 296- 300, 16-19 May 2006 40

41. New Research: FlexRPC (2007) • FlexRPC, a flexible user-level RPC system that enables to develop high-performance cluster file systems easily. • Ensures client-side thread-safeness and fully supports multithreaded RPC servers.   • Parallel and serial multicasting mechanisms • Concurrent call requests handled by worker threads on client and server side • Remote procedures are designed to be similar to SunRPC • Improves latency and bandwidth • Building a working prototype of cluster file system called Kadoop on top of FlexRPC. Sang-Hoon Kim; Youngjae Lee; Jin-Soo Kim; , "FlexRPC: A flexible Remote Procedure Call facility for modern cluster file systems," Cluster Computing, 2007 IEEE International Conference on , vol., no., pp.275-284, 17-20 Sept. 2007 41

42. New Research: Serial Multicast Info • Routing • Control plane, part of the router architecture, is concerned with drawing the network map, or the information in a routing table that defines what to do with incoming packets. • Multicast • Communication between a single sender and multiple receivers over a network • Routing requires an additional table for multicast routes. • Serial Multicasting • Instead of sending a RPC request to multiple receivers, each receiver forwards the RPC request to the “closest” receiver in the network topology that has not received the request 42

43. New Research: Serial Multicast (2009) • Modeling and evaluation of serial multicast remote procedure calls (RPCs) • Serial multicast RPC are needed in many distributed systems to avoid network bottlenecks and high-latency links • Present a mathematical model of serial multicast calls to better understand performance behavior • Model is very effective in predicting the performance of serial multicast RPCs. Sang-hoon Kim; Jin-Soo Kim; SeungryoulMaeng; , "Modeling and evaluation of serial multicast remote procedure calls (RPCs)," Communications Letters, IEEE , vol.13, no.4, pp.283-285, April 2009 43

44. New Research: WSN Info • Wireless sensor network (WSN) consists of spatially distributed autonomous sensors to monitor physical conditions http://en.wikipedia.org/wiki/Wireless_sensor_network http://embedsoftdev.com/embedded/wireless-sensor-network-wsn/ 44

45. New Research: SpartanRPC (2010) • Spartan RPC: Secure WSN middleware for cooperating domains • Middleware technology for wireless sensor network (WSN) applications supporting cooperation between distinct protection domains • SpartanRPC extends the nesC programming language • Provides a link-layer remote procedure call (RPC) mechanism • Incorporates capability-based security architecture for protection of RPC resources in heterogeneous environments Chapin, P.; Skalka, C.; , "SpartanRPC: Secure WSN middleware for cooperating domains," Mobile Adhoc and Sensor Systems (MASS), 2010 IEEE 7th International Conference on , vol., no., pp.61-70, 8-12 Nov. 2010 45

46. New Research: S-RPC (2011) • S-RPC, lightweight framework for remote procedure calls on wireless sensor and actuator nodes • Enables seamless interoperability between nodes with common interface to remote method invocations • Previous communication between embedded devices took place over proprietary protocols tailored for the given use case which limits integration of new functions • S-RPC  allows unified access to functions on remote devices • Permits dynamic integration of new devices with different functions into the network  Reinhardt, A.; Mogre, P.S.; Steinmetz, R.; , "Lightweight remote procedure calls for wireless sensor and actuator networks," Pervasive Computing and Communications Workshops (PERCOM Workshops), 2011 IEEE International Conference on , vol., no., pp.172-177, 21-25 March 2011 46

47. References • Ice in Wikipedia, http://en.wikipedia.org/wiki/Internet_Communications_Engine • InterprocessCommnications, http://en.wikipedia.org/wiki/Interprocess_communication • Randy Chow, Theodore Johnson, “Distributed Operating Systems & Algorithms”, 1997. • Shumko, Sergij. "Ice middleware in the New Solar Telescope's Telescope Control System". Astronomical Data Analysis Software and Systems XVII, ASP Conference Series, Vol. XXX, 2008., Canada. • Sun RPC, www.cdk4.net/additional/rmi/Ed2/SunRPC.pdf • Zeros, Inc. http://zeroc.com/ice.html