Request/Reply Communication

PURNANAND KUMAR
(CE)

Part I : Basic Information [1]

Introduction

Request /Reply communication

Remote Procedure Call (RPC)

RPC Operations

Parameter Passing and Data Conversion

Implementing RPC
Server management

RPC Exception and Failure Handling

Secure RPC

Introduction

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

Introduction Contd
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 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?

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 Contd

Call-by-value are fairly simple to handle

The client stub copies the value packages into a network message

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-byreference to the exit of the call

Parameter Passing Contd

Most RPC implementations assume that parameters

passed by call-by-value and call-by-copy/restore.

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

2. 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 Contd
3. Port mapper verifies the program and version numbers,

returns the port number of the server to the client.

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

directory server

Register service (if

server is unknown)

port mapper

2. create

1. register

3. port #
client

server
4. handle

RPC compilation
Compilation of RPC requires the followings:
1.

An interface specification file

2.

An RPC generator : input is the interface specification file and

output is the client and server stub procedure source codes.

3.

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 Contd

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 Contd

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 Contd

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 Contd

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 Contd

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.

Secure RPC
Security is important for RPC, since
1.

RPC introduces vulnerability because it opens doors for attacks.

2.

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 Contd

Authentication protocol for RPC should establish:
1.

Mutual authentication.

2.

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 Contd

Sun secure RPC

Built into Suns 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 Contd

Sun secure RPC example
1.

Client login attempt

2.

login program deposit the clients key in the key server.

3.

Key server generating a common session key, by exponential key

exchange.

4.

Secrete keys are erased after common session keys generated.

5.

Each RPC message is authenticated by a conversation key.

6.

Conversation key is kept in server, used for the entire session, as it is

not from the secrete key.

Secure RPC Contd

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.

Reference
1.

Randy Chow, Theodore Johnson, Distributed Operating Systems

& Algorithms, 1997

2.

Interprocess Commnications
http://en.wikipedia.org/wiki/Interprocess_communication

Thank
You