OPERATING

SYSTEM:
CSET209
 OUTLINE

 Distributed Systems

 Network vs Distributed OS

 RPC its structure and working

 Sun RPC and XDR

 1. DISTRIBUTED OPERATING SYSTEM S

• A distributed operating system is system software over a collection of

independent, networked, communicating, and physically separate
computational nodes.

• The distributed operating system manages a set of independent,

networked, communicating computers and makes them look like an
ordinary centralized operating system. Its main objective is to manage
hardware resources.
Few examples of a distributed OS are as follows: AIX
operating system for IBM RS/6000 computers. Solaris
operating system for SUN multiprocessor workstations
 S

DISTRIBUTED OPERATING SYSTEM

Advantages of Distributed OS
• The distributed operating system provides sharing of resources.

• This type of system is fault-tolerant.

Disadvantages of Distributed OS

• Protocol overhead can dominate computation cost.

 S

2. NETWORK OPERATING SYSTEM

• Network operating systems are server-based operating systems that provide networking-
related functionality. Its primary objective is to give local services to remote users. It's all
nodes can have a different operating system.

Examples of Network Operating System are: Microsoft

Windows Server 2003, Microsoft Windows Server
2008, UNIX, Linux

• It can be used for providing file server, email

server etc. services over the network.
 S

NETWORK OPERATING SYSTEM

Advantages of Network OS
• In this type of operating system, network traffic reduces due to the division between
clients and the server.
• This type of system is less expensive to set up and maintain.
Disadvantages of Network OS
• In this type of operating system, the failure of any node in a system affects the whole
system.
• Security and performance are important issues. So trained network administrators are
required for network administration.
 SYSTEM

S.NO Network Operating System Distributed Operating System

Network Operating System’s main objective is Distributed Operating System’s main objective is to
1.
to provide the local services to remote client. manage the hardware resources.

In Distributed Operating System, Communication

In Network Operating System, Communication
2. takes place on the basis of messages and shared
takes place on the basis of files.
memory.

Network Operating System is more scalable Distributed Operating System is less scalable than
3.
than Distributed Operating System. Network Operating System.

In Network Operating System, fault tolerance is While in Distributed Operating System, fault
4.
less. tolerance is high.

Ease of implementation in Network Operating While in Distributed Operating System Ease of

5.
System is also high. implementation is less.

In Network Operating System, All nodes can While in Distributed Operating System, All nodes
6.
have different operating system. have same operating system.
NOS VS DOS IN TERMS OF SYSTEM DESIGN AND USER EXPERIENCE.

System Design

Distributed Operating System

Feature Network Operating System (NOS)
(DOS)
Loosely coupled; each node has its Tightly integrated; appears as one
Architecture
own OS. system.
Each system manages its own Centralized/global resource
Resource Management
resources independently. management across nodes.
Users or applications explicitly
Communication is handled
Communication manage communication (e.g., file
transparently by the system.
sharing, remote login).
Easier to scale by adding new More complex to scale due to
Scalability
independent systems. coordination overhead.
Failures affect only the affected Can provide higher fault tolerance via
Fault Tolerance
system. redundancy and replication.
NOS VS DOS IN TERMS OF SYSTEM DESIGN AND USER EXPERIENCE.

User Experience

Distributed Operating System

Feature Network Operating System (NOS)
(DOS)
Low; users are aware of multiple
High; users see the system as a single
Transparency systems (e.g., accessing remote
cohesive unit.
resources manually).
Unified file system; files can be
Separate file systems per machine;
File System accessed without knowing their
user must specify remote access paths.
physical location.
System can schedule and migrate
Users manage processes on individual
Process Management processes transparently across
systems.
machines.
More effort needed to interact with
Ease of Use Easier, as all resources seem local.
remote resources.
 3. REMOTE PROCEDURE CALL (RPC) PROTOCOL IN DISTRIBUTED SYSTEM

 Remote Procedure Call is

a software communication
protocol that one program can use
to request a service from a program
located in another computer on
a network without having to
understand the network's details.
 RPC uses the client-server model.
 NOTE: RPC is especially well
suited for client-server (e.g. query-
response) interaction in which the
flow of control alternates between
the caller and callee.
 Example Applications: Remote
file and database access, remote
monitoring program control,
remote error logging etc.
 TYPES OF PARAMETER PASSING IN RPC

• Call-by-Value: A copy of the data is sent to the remote server. Changes made
on the server do not affect the original variable on the client.
• Call-by-Reference: Instead of copying, a reference to the data is passed.
However, true call-by-reference is not feasible across networks, so it’s usually
simulated using handles or additional communication.
• Call-by-Result: Only the output result is returned to the caller.
• Call-by-Value-Result: Combines call-by-value and call-by-result—parameters
are sent and updated values are returned.
 IMPORTANCE OF PARAMETER PASSING IN RPC

Transparency:
• Goal: RPC aims to make remote calls as similar to local calls as possible.
• Proper parameter passing ensures interface transparency, hiding the complexities of data
transmission from the developer.
• Issues like data marshalling (converting parameters to a transmittable format) and unmarshalling are
handled by the RPC mechanism to preserve this abstraction.
Correctness:
• Incorrect parameter handling (e.g., not considering differences in data representation or endianness)
can lead to bugs or crashes.
• Ensures that input/output semantics are preserved across different systems.
Efficiency:
• Large or complex parameters can cause performance bottlenecks due to serialization overhead and
network latency.
• Efficient marshalling, minimizing data transfer, and avoiding unnecessary parameter copies are
critical for performance.
 Effects on Transparency and Efficiency

Aspect Impact of Parameter Passing

Makes the remote procedure call appear like a
Transparency local one; poor parameter handling breaks
this illusion.
Affects serialization/deserialization cost,
Efficiency network usage, and processing time on both
client and server sides.
Impacts error handling and fault tolerance in
Robustness
case of transmission or format mismatches.
 HOW TO MAKE A REMOTE PROCEDURE CALL?
 The following steps take place during a RPC :
1. A client invokes a client stub procedure, passing parameters in the
usual way. The client stub resides within the client’s own address
space.
2. The client stub marshalls(pack) the parameters into a message.
Marshalling includes converting the representation of the parameters
into a standard format, and copying each parameter into the message.
3. The client stub passes the message to the transport layer, which sends it
to the remote server machine.
4. On the server, the transport layer passes the message to a server stub,
which demarshalls(unpack) the parameters and calls the desired
server routine using the regular procedure call mechanism.
5. When the server procedure completes, it returns to the server stub (e.g.,
via a normal procedure call return), which marshalls the return
values into a message. The server stub then hands the message to the
transport layer.
6. The transport layer sends the result message back to the client transport
layer, which hands the message back to the client stub.
7. The client stub demarshalls the return parameters and execution returns
to the caller.
 ISSUES AND CHALLENGES IN RPC

 1. RPC Runtime:
RPC run-time system is a library of routines and a set of services that handle the network communications
that underlie the RPC mechanism. In the course of an RPC call, client-side and server-side run-time systems’
code handle binding, establish communications over an appropriate protocol, pass call data between the
client and server, and handle communications errors.
 2. Stub:
The function of the stub is to provide transparency to the programmer-written application code.
• On the client side, the stub handles the interface between the client’s local procedure call and the run-time
system, marshaling and unmarshalling data, invoking the RPC run-time protocol, and if requested, carrying
out some of the binding steps.
• On the server side, the stub provides a similar interface between the run-time system and the local manager
procedures that are executed by the server.
 3. Binding: How does the client know who to call, and where the service resides?
The most flexible solution is to use dynamic binding and find the server at run time when the RPC is first
made.
 FEATURES OF RPC

In an operating system, remote procedure call (RPC) has the following

features, such as:
 RPC hides the complexity of the message passing process from the user.
 RPC only uses specific layers of the OSI model like the transport layer.
 Clients can communicate with the server by using higher-level languages.
 RPC works well with both local environments and remote environments.
 4 SUN RPC AND ROLE OF XDR

• The first popular implementation of RPC on Unix was Sun's RPC (now called ONC
RPC), used as the basis for Network File System (NFS).
• Role of XDR in Sun RPC: RPC package uses XDR (eXternal Data Representation)
to represent data sent between client and server stubs.
• In Sun RPC The XDR (eXternal Data Routines) are responsible for
marshalling/unmarshalling procedure parameters onto/from XDR streams.
THANK YOU
?