III BSc (Semester – VI) Distributed Systems Unit II

UNIT II
Features of Message Passing System, Synchronization and Buffering,
Introduction to RPC and its models, Transparency of RPC,
Implementation Mechanism, Stub Generation and RPC Messages, Server
Management, Call Semantics, Communication Protocols and Client
Server Binding.
*******************
1. Explain Features of Message Passing System.
Message Passing system is subsystem of Distributed System that
provides a set of message based IPC protocol and does so by hiding
details of complex network protocols and multiples heterogeneous
platform from programmers.

Features of Message Passing:

Simplicity: Simple and Ease to use. Simple and Clear Semantics of IPC
Protocols of message passing makes it easier.
• Uniform Semantics: There are two types of communication :
o Local
o Remote
1. Semantics of Remote should be as close as possible to
local communication for ease of use.
• Efficiency :
o It can be made efficient by reducing number of message
exchange.
o Avoiding cost of setting and terminating connections
between the same pair.
o Minimizing the cost of maintaining connections.
o Piggybacking.
• Reliability :
o Distributed System is prone to node crashes or
communication link failure resulting into loss of data.
o Handling of lost message
• Duplicate messages, capable of detecting and handling duplicates.
• Generating and assigning appropriate sequences

1 Prepared By P.Y.Kumar © www.anuupdates.org

III BSc (Semester – VI) Distributed Systems Unit II
• Correctness :
o Issues
• Atomicity: Message to All of None.
• Order Delivery: Message in Order.
• Survivability: Message delivery despite of partial failure.
• Flexibility :
o User may choose types and level of reliability
o Synchronous/Asynchronous, Send/Receive Choice.
• Security:
o It must provide secure end to end communication.
o Necessary Steps:
• Authentication of receiver by sender.
• Authentication of sender by receiver.
• Portability:
o Two Aspects:
• Message passing system should itself be portable.
• Applications written by using primitives of IPC Protocols of
Message Passing System should be Portable.

2. Synchronization and Buffering.

A central issue in the communication structure is the
synchronization imposed on the communicating processes by the
communication primitives. The semantics used for synchronization may
by broadly classify as blocking and non blocking types. A primitive is
said to have non blocking semantics if its invocation does not block the
execution of its invoker (the control returns almost immediately to the
invoker); otherwise a primitive is said to be of the blocking type.

In case of a blocking send primitive, after execution of the send

statement, the sending process is blocked until it receives an
acknowledgement from the receiver that the message has been
received. On the other hand, for non blocking send primitive, after
execution of the send statement, the sending process is allowed to
proceed with its execution as soon as the message has been copied to a
buffer.
In the case of blocking receive primitive, after execution of the
receive statement; the receiving process is blocked until it receives a
message. On the other hand, for a non blocking receive primitive,
the receiving process proceeds with its execution after execution of the
receive statement, which returns control almost immediately just after
telling the kernel where the message buffer is.

2 Prepared By P.Y.Kumar © www.anuupdates.org

III BSc (Semester – VI) Distributed Systems Unit II
An important issue in a non blocking receive primitive is how the
receiving process knows that the message has arrived in the message
buffer. One of the following two methods is commonly used for this
purpose:
• Polling. In this method, a test primitive is provided to allow the
receiver to check the buffer status. The receiver uses this primitive to
periodically poll the kernel to check if the message is already
available in the buffer.
• Interrupt. In this method, when the message has been filled in the
buffer and is ready for use by the receiver, a software interrupt is
used to notify the receiving process.
A variant of the non blocking receive primitive is the conditional
receive primitive, which also returns control to the invoking process
almost immediately, either with a message or with an indicator that no
message is available.
When both the send and receive primitives of a communication
between two processes use blocking semantics, the communication is
said to be synchronous, otherwise it is asynchronous. The main
drawback of synchronous communication is that it limits concurrency
and is subject to communication deadlocks.

Synchronous mode of communication with both sends and

receives primitives having blocking-type semantics.

3 Prepared By P.Y.Kumar © www.anuupdates.org

III BSc (Semester – VI) Distributed Systems Unit II
Buffering:
In the standard message passing model, messages can be copied
many times: from the user buffer to the kernel buffer (the output buffer
of a channel), from the kernel buffer of the sending computer (process)
to the kernel buffer in the receiving computer (the input buffer of a
channel), and finally from the kernel buffer of the receiving computer
(process) to a user buffer.

Null Buffer (No Buffering)

In this case, there is no place to temporarily store the message.

Hence one of the following implementation strategies may be used:

• The message remains in the sender process’s address space and the
execution of the send is delayed until the receiver executes the
corresponding receive.

• The message is simply discarded and the time-out mechanism is

used to resend the message after a timeout period. The sender may
have to try several times before succeeding.
The three types of buffering strategies used in interprocess
communication

4 Prepared By P.Y.Kumar © www.anuupdates.org

III BSc (Semester – VI) Distributed Systems Unit II
Single-Message Buffer
In single-message buffer strategy, a buffer having a capacity to
store a single message is used on the receiver’s node. This strategy is
usually used for synchronous communication; an application module
may have at most one message outstanding at a time.

Unbounded-Capacity Buffer
In the asynchronous mode of communication, since a sender does
not wait for the receiver to be ready, there may be several pending
messages that have not yet been accepted by the receiver. Therefore,
an unbounded-capacity message-buffer that can store all unreceived
messages is needed to support asynchronous communication with the
assurance that all the messages sent to the receiver will be delivered.

Finite-Bound Buffer
Unbounded capacity of a buffer is practically impossible.
Therefore, in practice, systems using asynchronous mode of
communication use finite-bound buffers, also known as multiple-
message buffers. In this case message is first copied from the sending
process’s memory into the receiving process’s mailbox and then copied
from the mailbox to the receiver’s memory when the receiver calls for
the message.
When the buffer has finite bounds, a strategy is also needed for
handling the problem of a possible buffer overflow. The buffer overflow
problem can be dealt with in one of the following two ways:

• Unsuccessful communication. In this method, message transfers

simply fail, whenever there is no more buffer space and an error is
returned.

Flow-Controlled Communication The second method is to use flow

control, which means that the sender is blocked until the receiver
accepts some messages, thus creating space in the buffer for new
messages. This method introduces synchronization between the sender
and the receiver and may result in unexpected deadlocks. Moreover,
due to the synchronization imposed, the asynchronous send does not
operate in the truly asynchronous mode for all send commands.

3. Introduction to RPC and its models.

This chapter provides a general description of the programming

model implemented by the RPC Application Programming Interface
(API). This description includes definitions of many of the concepts used
throughout the RPC API manual pages. As such, it is a necessary
prerequisite to the understanding of the manual pages, and the manual
pages assume knowledge of this chapter, even when they do not make
explicit reference to it.

5 Prepared By P.Y.Kumar © www.anuupdates.org

III BSc (Semester – VI) Distributed Systems Unit II
The description serves three purposes:
ü It provides general information that is relevant to many of the
routines in the RPC API, but is not specified in the individual
manual pages.
ü It provides a rationale for the set of RPC APIs included in this
document.
ü It provides general guidelines for the intended use of the RPC
APIs.
The general information covers topics, such as binding and name
service usage that are relevant to many of the manual pages. Typically,
several routines perform tasks related to a given topic. This introduction
provides a general model within which the tasks performed by individual
routines and suites of routines can be understood. This general model
also provides a rationale for the set of routines included in this
document. It describes the underlying operations required for RPC
programming and shows how the set of RPC APIs included in this
document gives access to these operations.
In showing how the RPC API routines are meant to be used, this
chapter provides certain guidelines for consistent RPC client/server
interface usage. These guidelines cover such areas as using the naming
services and organizing server resources. By following them,
programmers can simplify the task of maintaining and enhancing server
interfaces and writing client programs.

RPC Programming Model Overview

The RPC programming model can be viewed along two axes:
ü client/server
ü Program/stub/run-time system.
Each view describes important aspects of the use of the RPC API.
Client/Server Model
The client/server view of RPC programming describes the
distributed resource model implemented by the RPC mechanism. In this
view, programming tasks are divided between servers, which provide
services or make resources available to remote clients, and clients,
which seek and make use of these services or resources.
Interfaces
The central component of the client/server model is the interface.
An interface is a set of remotely callable operations offered by a server
and inviolable by clients. Interfaces are implemented by managers,
which are sets of server routines that implement the interface
operations. RPC offers an extensive set of facilities for defining,
implementing and binding to interfaces.

6 Prepared By P.Y.Kumar © www.anuupdates.org

III BSc (Semester – VI) Distributed Systems Unit II
The RPC mechanism itself imposes few restrictions on the
organization of operations into interfaces. RPC does provide a means to
specify interface versions and a protocol to select a compatible interface
version at bind time (see Interface Definition Language and Remote
Procedure Call Model). When an interface is specified as a new version
of an existing interface, the server manager code must provide the
required version compatibility. Beyond this restriction, the programmer
is free to place any set of remotely callable operations in a given
interface.
Remoteness
The RPC paradigm makes remote calls an extension of the familiar
local procedure call mechanism. Specifically, the call itself is made as a
local procedure call, and the underlying RPC mechanism handles the
remoteness transparently. Server interface programming is thus similar
to local procedure call programming, except that the handler of the call
runs in a separate address space and security domain.
From this point of view, a local procedure call is a special simple
case of the more general call mechanism provided by RPC. RPC
semantics extend local procedure call semantics in a variety of ways:
Reliability
Network transports may offer varying degrees of reliability.
The RPC run-time system handles these transport semantics
transparently, but RPC call specifications include a specification
of execution semantics that indicates to the RPC protocols the
required guarantees of success and the permissibility of multiple
executions on a possibly unreliable transport. Server application
code must be appropriate for the specified execution semantics.
Binding
RPC binding occurs at run time and is under program
control. Client and server use of the RPC binding mechanism is
discussed extensively in this chapter.
No Shared Memory
Because calling and called procedures do not share the
same address space, remote procedure calls with input/output
parameters use copy-in, copy-out semantics. For the same
reason, RPC has no notion of "global data structures" shared
between the caller and callee; data must be passed via call
parameters.
Failure Modes
A number of failure possibilities arise when the caller and
callee are on physically separate machines. These include remote
system or server crashes, communications failures, security

7 Prepared By P.Y.Kumar © www.anuupdates.org

III BSc (Semester – VI) Distributed Systems Unit II
problems and protocol incompatibilities. RPC includes a
mechanism to return such remote errors to the caller.
Cancels
RPC extends the local cancel mechanism by forwarding
cancels that occur during an RPC to the server handling the call,
allowing the server application code to handle the cancel. RPC
adds a cancel time-out mechanism to ensure that a caller can
regain control within a specified amount of time if a cancelled call
should fail to return.
Security
Executing procedures across physical machine boundaries
and over a network creates additional requirements for security.
The RPC API includes an interface to the underlying security
services
API Operations
The RPC API provides access to an extensive set of run-time
operations. RPC API Routine Taxonomy provides a detailed taxonomy of
APIs according to the operations performed. This section offers an
overview, based on a somewhat broader set of categories.
ü binding-related operations
ü name service operations
ü endpoint operations
ü security operations
ü stub memory management operations
ü management operations
ü UUID operations.
Subsequent sections of this chapter cover many of these groups of
operations in detail.
Binding-related Operations
Binding-related operations establish a relationship between a client
and server that makes possible a remote procedure call. These
operations may be roughly divided into two categories:
ü Operations to establish client/server communications using an
appropriate protocol
ü Operations that establish internal call routing information for the
server.
Operations in the first category include the creation of
communications endpoints by the server for the set of protocols over
which it wishes to receive remote procedure calls. Servers typically
export information about the bindings thus created to a name service
and an endpoint map. Clients typically import such binding information
from a name service and an endpoint map.

8 Prepared By P.Y.Kumar © www.anuupdates.org

III BSc (Semester – VI) Distributed Systems Unit II
Operations in the second category establish a set of mappings that
the server can use to route calls internally to the appropriate manager
routine. This routing is based on the interface and version, operation
and any object requested by the call.
Name Service Operations
The RPC name service API includes an extensive set of operations
for exporting and importing binding information to and from name
services. These operations make use of a set of RPC-specific name
service entry attributes to structure the exported binding information so
that it can easily be found and interpreted by clients.
Endpoint Operations
Servers listen for remote procedure call requests over one or
more protocol-specific endpoints. Typically, such endpoints are allocated
dynamically when a server begins to listen, and their lifetime is only a
single server instantiation. RPC provides an endpoint
mapper mechanism that allows such volatile endpoint information to be
maintained separately from the more stable components of a binding.
Typically, servers export stable binding information to a name
service and register their volatile endpoints with the local endpoint
mapper. The endpoint mapper then resolves endpoints for calls made on
bindings that do not contain them. Endpoint operations are used by
servers to register their endpoints with the endpoint mapper.
Security Operations
These operations establish the authentication and authorization
services and protection levels used by remote procedure calls.
Internationalization Support Operations
These operations are used by applications to implement character
and code set interoperability, which permits clients and servers to
transfer international character data in a heterogeneous character set
and code sets environment.
Stub Memory Management Operations
These operations are used by applications to manage stub
memory. They are typically used by RPC applications that pass pointer
data.
Management Operations
Management operations include a variety of operations with the
potential to affect applications other than the one making the
management call. Servers automatically export a set of remote
management functions.

9 Prepared By P.Y.Kumar © www.anuupdates.org

III BSc (Semester – VI) Distributed Systems Unit II
UUID Operations
UUIDs (Universal Unique Identifiers) are used frequently by
the RPC mechanism for a variety of purposes. The UUID operations
enable applications to manipulate UUIDs.
Binding
Binding refers to the establishment of a relationship between a client
and a server that permits the client to make a remote procedure call to
the server. In this document, the term "binding" usually refers
specifically to a protocol relationship between a clients and either the
server host or a specific endpoint on the server host, and "binding
information" means the set of protocol and addressing
information required to establish such a binding. But, for a remote
procedure call, such a binding occurs in a context that involves other
important elements, paralleling the notion of a binding in a local
procedure call. In order for an RPC to occur, a relationship must be
established that ties a specific procedure call on the client side with the
manager code that it invokes on the server side. This requires both the
binding information itself and a number of additional elements. The
complete list is as follows:

ü A protocol sequence that identifies the RPC and underlying

transport protocols
ü An RPC protocol version identifier
ü A transfer syntax identifier
ü A server host network address
ü An endpoint of a server instance on the host
ü An object UUID that can optionally be used for selection among
servers and/or manager routines
ü An interface UUID that identifies the interface to which the called
routine belongs
ü An interface version number that defines compatibility between
interface versions
ü An operation number that identifies a specific operation within the
interface.

10 Prepared By P.Y.Kumar © www.anuupdates.org

III BSc (Semester – VI) Distributed Systems Unit II

Figure: Information Required Completing an RPC

4. Communication Protocols and Client Server Binding.

Client/Server Terminology:
Applications Programming Interface (API)
A set of function and call programs that allow clients and servers
to intercommunicate
Client
A networked information requester, usually a PC or workstation,
that can query database and/or other information from a server
Middleware
A set of drivers, APIs, or other software that improves
connectivity between a client application and a server
Relational Database
A database in which information access is limited to the selection
of rows that satisfy all search criteria
Server
A computer, usually a high-powered workstation, a minicomputer,
or a mainframe, that houses information for manipulation by networked
clients.

11 Prepared By P.Y.Kumar © www.anuupdates.org

III BSc (Semester – VI) Distributed Systems Unit II
Structured Query Language (SQL)
A language developed by IBM and standardized by ANSI for
addressing, creating, updating, or querying relational databases.

Client/Server Computing:

Client:

Client machines are generally single-user workstations providing a

user-friendly interface to the end user
ü Client-based stations generally present the type of graphical
interface that is most comfortable to users, including the use of
windows and a mouse
ü Microsoft Windows and Macintosh OS provide examples of such
interfaces
ü Client-based applications are tailored for ease of use and include
such familiar tools as the spreadsheet

Client/Server Computing: Server

Each Server provides a set of shared services to the clients

ü Most common type of server currently is the database server,
usually controlling a relational database
ü Enables many clients to share access to the same database
ü Enables the use of a high-performance computer system to
manage the database

12 Prepared By P.Y.Kumar © www.anuupdates.org

III BSc (Semester – VI) Distributed Systems Unit II
Client/Server Characteristics:
A client/server configuration differs from other types of distributed
processing:
ü There is a heavy reliance on bringing user-friendly applications to
the user on his or her own system
ü There is an emphasis on centralizing corporate databases and
many network management and utility functions
ü There is a commitment, both by user organizations and vendors,
to open and modular systems
ü Networking is fundamental to the operation.

Client/Server Applications:
The key feature of client/server architecture is the allocation of
application-level tasks between clients and servers
ü Hardware and the operating systems of client and server may
differ
ü These lower-level differences are irrelevant as long as a client and
server share the same communications protocols and support the
same applications
ü It is the communications software that enables client and server
to interoperate
Ø principal example is TCP/IP
ü Actual functions performed by the application can be split up
between client and server in a way that optimizes the use of
resources

13 Prepared By P.Y.Kumar © www.anuupdates.org

III BSc (Semester – VI) Distributed Systems Unit II
ü The design of the user interface on the client machine is critical
Ø There is heavy emphasis on providing a graphical user
interface (GUI) that is easy to use, easy to learn, yet
powerful and flexible

Classes of Client/Server Applications:

14 Prepared By P.Y.Kumar © www.anuupdates.org

III BSc (Semester – VI) Distributed Systems Unit II

ü Not true client/server computing

ü Traditional mainframe environment in which all or virtually all of
the processing is done on a central host
ü Often the user interface is via a dumb terminal
ü The user’s station is generally limited to the role of a terminal
emulator

15 Prepared By P.Y.Kumar © www.anuupdates.org