4.2 Request/Reply Communication Wooyoung Kim Fall 2009

Part I : Basic Information [1] Introduction Request /Reply communication Remote Procedure Call (RPC) RPC Operations Parameter Passing and Data Conversion Binding RPC compilation RPC Exception and Failure Handling Secure RPC

Introduction Request/Reply Communication Common technique for one application to request the services of another.

Introduction – Cont’d Remote Procedure Call (RPC) Most widely used request/reply communication model A language-level abstraction of the request/reply communication mechanism How RPC work? What is the implementation issues for RPC?

RPC vs. local procedure call. RPC Operations RPC vs. local procedure call. Similar in syntax as two have ‘calling’ and ‘waiting’ procedures – RPC provides access transparency to remote operations. Different in semantics, because RPC involves delays and failures (possibly).

RPC Operations – how it works? This operation exposes some issues when implementing

RPC Operations – implementation issues Parameter passing and data conversion. Binding – locating server and registering the service Compilation – origination of stub procedures and linking Exception and failure handling Security

Parameter Passing In a single process : via parameters and/or global variables In multiple processes on the same host : via message passing . However, RPC-based clients and servers : passing parameters is typically the only way Parameter marshaling : Rules for parameter passing and data/message conversion. Primary responsibility of Stub procedure

Parameter Passing – Cont’d Call-by-value are fairly simple to handle The client stub copies the value packages into a network message Call-by -name requires dynamic run-time evaluation of symbolic expression. Call-by-reference is 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

Parameter Passing – Cont’d Most RPC implementations assume that parameters passed by call-by-value and call-by-copy/restore.

Data Conversion Three problems in conversion between data and message Data typing Data representation Data transfer syntax

Data Conversion – Cont’d Type checking across machines is difficult, because the data is passed through interprogram messages. Data should carry type information? Each machine has its own internal representation of the data types. Complicated by the Serial representation of bits and bytes in communication channels. Different machines have different standards for the bits or bytes with the least or the most significant digit first.

Data Conversion – Cont’d Transfer syntax Rules regarding of messages in a network. For n data representations, n*(n-2)/2 translators are required. Better solution: inventing an universal language : 2*n translators. However, this increase the packing/unpacking overhead.

Data Conversion – Cont’d ASN.1 Abstract Syntax Notation One Most important developments in standards. Used to define data structures. Used for specifying formats of protocol data units in network communications.

Data Conversion – Cont’d ASN.1 and transfer syntax are the major facilities for building network presentation services. ASN.1 can be used directly in data representation for RPC implementations. Data types are checked during stub generation and compilation. Providing type information in messages is not necessary.

Data Conversion– Cont’d Examples of canonical data representations for RPC Sun ’s XDR: eXternal Data Representation DCE’s IDL : Interface Definition Language

Binding 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.

Binding – Cont’d The server, when it 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.

Binding – Cont’d 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.

Server machine address or handle to server Binding – Cont’d 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

RPC compilation 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 Exception and Failure Handling Exceptions Abnormal conditions raised by the execution of stub and server procedures. Ex. Overflow/underflow, protection violation. Failures Problems caused by crashes of clients, servers, or the communication network.

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?

Exception Handling – Cont’d 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.

Failure Handling 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.

Failure Handling – Cont’d Problem with Retransmission of requests. In case of delay, server get multiple requests -> make it idempotent (can be executed multiple times with the same effect) In case of idempotent impossible (lock servers), each request has sequence number. Typical RPC do not use sequence numbers – only requests-based.

Failure Handling – Cont’d 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.

Failure Handling – Cont’d 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

Failure Handling – Cont’d Most desirable RPC semantics is 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.

Failure Handling – Cont’d Crash of a client process. Server has an orphan computation and its reply is undeliverable. orphan computation waist server resources, may confuse the client with invalid replies from previous connections. How to eliminate orphan computation? Client: On reboot, cleans up all previous requests. Server: Occasionally locate owners of requests. Expiration: Each remote operation is given a maximum lifetime.

Secure RPC Security is important for RPC, since RPC introduces vulnerability because it opens doors for attacks. RPC became a cornerstone of client/server computation. All security features should be build on top of a secure RPC. Primary security issues Authentication of processes. Confidentiality of messages. Access control authorization from client to server.

Secure RPC – Cont’d 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.

Secure RPC – Cont’d Sun 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 cryptographical session key. When user login, NIS gives the key. With user password, the key used to decrypt the secret key, discard password. Password are not transmitted in the network.

Secure RPC – Cont’d Sun secure RPC – example Client login attempt login program deposit the client’s key in the key server. Key server generating a common session key, by exponential key exchange. Secrete keys are erased after common session keys generated. Each RPC message is authenticated by a conversation key. Conversation key is kept in server, used for the entire session, as it is not from the secrete key.

Secure RPC – Cont’d 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.

SUN’S SECURE RPC

Other RPC Industry Implementations [2] Part II : Current Projects Other RPC Industry Implementations [2] 1984 - ONC RPC/NFS (Sun Microsystems Inc.) Early 1990s - DCE RPC (Microsoft) Late 1990’s – ORPC (Object Oriented Programming Community) 1997 – DCOM (Microsoft) 2002 - .NET Remoting (Microsoft) Doors (Solaris) 2003-ICE (Internet Communications Engine) DCOP - Desktop Communication Protocol (KDE)

ICE (Internet Communications Engine) [3,4,5] ICE is object-oriented middleware providing RPC, grid computing, and publish/subscribe functionality. Influenced by CORBR (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.

ICE components Figure from www.wikipedia.org

ICE components IceStorm: object-oriented publish-and-subscribe framework IceGrid: provide object-oriented load balancing, failover, object-discovery and registry services. IcePatch :facilitates the deployment of ICE based software Glacier: a proxy-based service to enable communication through firewalls IceBox: a SOA-like container of executable services implemented with libraries Slice: file format that programmers follow to edit. Servers should communicate based on interfaces and classes as declared by the slice definitions.

Current Project with ICE [5] 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 Telescope Pointing Tracking Subsystem Active Optics Control Subsystem Handheld Controller Main GUI

Current Project with ICE-Cont’d [5] Ice advantages Provides fast and scalable communications. Simple to use 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. Ice problem Frequent package updates cause changes of coding.

Current Project with ICE-Cont’d [5] TCS Implementation 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.

Part III : Future Works Compatible updates with old versions (ex. ICE) Trend on Object-oriented implementation: General-purpose tool to construct object-based modular systems, transparently distributed at run-time.

Reference Randy Chow, Theodore Johnson, “Distributed Operating Systems & Algorithms”, 1997 Interprocess Commnications http://en.wikipedia.org/wiki/Interprocess_communication Zeros, Inc. http://zeroc.com/ice.html ICE in wikipedia, http://en.wikipedia.org/wiki/Internet_Communications_Engine 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.

Thank You