3. 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
4. DISTRIBUTED OPERATING SYSTEM
S
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.
5. 2. NETWORK OPERATING SYSTEM
S
• 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.
6. NETWORK OPERATING SYSTEM
S
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.
7. S.NO Network Operating System Distributed Operating System
1.
Network Operating System’s main objective is to provide
the local services to remote client.
Distributed Operating System’s main objective is to manage the
hardware resources.
2.
In Network Operating System, Communication takes place
on the basis of files.
In Distributed Operating System, Communication takes place on
the basis of messages and shared memory.
3.
Network Operating System is more scalable than
Distributed Operating System.
Distributed Operating System is less scalable than Network
Operating System.
4. In Network Operating System, fault tolerance is less. While in Distributed Operating System, fault tolerance is high.
5.
Ease of implementation in Network Operating System is
also high.
While in Distributed Operating System Ease of implementation is
less.
6.
In Network Operating System,All nodes can have different
operating system.
While in Distributed Operating System,All nodes have same
operating system.
NETWORKVS DISTRIBUTED OPERATING SYSTEM
8. NOS VS DOS IN TERMS OF SYSTEM DESIGN AND USER EXPERIENCE.
Feature Network Operating System (NOS)
Distributed Operating System
(DOS)
Architecture
Loosely coupled; each node has its
own OS.
Tightly integrated; appears as one
system.
Resource Management
Each system manages its own
resources independently.
Centralized/global resource
management across nodes.
Communication
Users or applications explicitly
manage communication (e.g., file
sharing, remote login).
Communication is handled
transparently by the system.
Scalability
Easier to scale by adding new
independent systems.
More complex to scale due to
coordination overhead.
Fault Tolerance
Failures affect only the affected
system.
Can provide higher fault tolerance via
redundancy and replication.
System Design
9. NOS VS DOS IN TERMS OF SYSTEM DESIGN AND USER EXPERIENCE.
User Experience
Feature Network Operating System (NOS)
Distributed Operating System
(DOS)
Transparency
Low; users are aware of multiple
systems (e.g., accessing remote
resources manually).
High; users see the system as a single
cohesive unit.
File System
Separate file systems per machine;
user must specify remote access paths.
Unified file system; files can be
accessed without knowing their
physical location.
Process Management
Users manage processes on individual
systems.
System can schedule and migrate
processes transparently across
machines.
Ease of Use
More effort needed to interact with
remote resources.
Easier, as all resources seem local.
10. 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.
11. 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.
12. 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.
13. Aspect Impact of Parameter Passing
Transparency
Makes the remote procedure call appear like a local one;
poor parameter handling breaks this illusion.
Efficiency
Affects serialization/deserialization cost, network usage,
and processing time on both client and server sides.
Robustness
Impacts error handling and fault tolerance in case of
transmission or format mismatches.
Effects on Transparency and Efficiency
14. 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.
15. 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.
16. 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.
17. 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.
