1. 4.2 Request/Reply Communication
Wooyoung Kim
Fall 2009

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

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

4. 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?

5. 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

23. 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?

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

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

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

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

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

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

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

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

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

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

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

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

36. SUN’S SECURE RPC

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

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

39. ICE components
Figure from

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

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

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

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

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

45. Reference
Randy Chow, Theodore Johnson, “Distributed Operating Systems & Algorithms”, 1997
Interprocess Commnications
Zeros, Inc.
ICE in wikipedia,
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.

46. Thank You