Module – 3

The Operating System Layer

Key Concepts:

1. Middleware and OS Integration:

o Middleware operates on various OS–hardware combinations in distributed
systems.
o OS provides abstractions of local hardware resources (processing, storage,
communication) for middleware.
2. User Satisfaction:
o Good performance of the middleware–OS combination is essential for user
satisfaction.
3. OS Role in Middleware:
o The OS layer supports middleware to provide distributed infrastructure for
applications.
o Middleware depends on OS mechanisms for remote invocations and resource
sharing.

Essential Requirements for OS and Middleware:

1. Encapsulation:
o Resources must provide useful interfaces for clients.
o Internal details (memory and device management) should remain hidden.
2. Protection:
o Resources must be protected against unauthorized access (e.g., file
permissions, device access).
3. Concurrent Processing:
o OS must support concurrency, ensuring multiple clients can access shared
resources transparently.
4. Invocation Mechanisms:
 o Support remote method invocations or system calls to access encapsulated
resources.
o Key tasks include:
§ Communication: Transfer parameters/results over a network or
locally.
§ Scheduling: Allocate processing time for invoked operations.

Core OS Functionality:

1. Process Manager:
o Manages creation and operations of processes.
o Each process includes an address space and one or more threads.
2. Thread Manager:
o Manages thread creation, synchronization, and scheduling.
o Threads are the active, schedulable units within processes.
3. Communication Manager:
o Facilitates communication between threads in the same process or across
processes.
o External communication support varies across kernels.
4. Memory Manager:
o Oversees physical and virtual memory management.
o Optimizes data copying and sharing for efficiency.
5. Supervisor (Hardware Abstraction Layer):
o Handles interrupts, exceptions, system call traps, and low-level hardware
operations.
o Minimizes machine-dependent code through layering.
Processes and Threads

Challenges with Traditional Processes

1. Traditional single-threaded processes were inadequate for distributed systems and

sophisticated single-computer applications requiring internal concurrency.
2. Sharing resources between activities in traditional processes was awkward and
expensive.

Enhanced Process Model

1. Modern Process:
o Consists of an execution environment and one or more threads.
o Threads represent the OS abstraction of activities ("thread of execution").
2. Execution Environment:
o Unit of resource management shared by all its threads.
o Includes:
§ Address space.
§ Thread synchronization and communication tools (e.g.,
semaphores, sockets).
§ Higher-level resources (e.g., open files, windows).
o Acts as the protection domain for its threads.
3. Threads:
o Enable concurrent execution, improving efficiency.
o Can be dynamically created and destroyed.
o Allow overlapping of computation with I/O operations.
o Support concurrent processing, particularly beneficial in servers to handle
multiple client requests simultaneously.

Advantages of Multi-threading

1. Concurrency:
o Maximizes execution overlap between operations.
o Enhances performance on multiprocessors and I/O-bound systems.
2. Reduced Bottlenecks:
o In servers, threads reduce bottlenecks by enabling concurrent handling of
multiple client requests.

Protection and Resource Sharing

1. Threads in one execution environment are protected from threads in other

environments by default.
2. Some kernels allow controlled resource sharing (e.g., physical memory) between
execution environments on the same computer.
Terminology and Distinctions

1. Multi-threaded Process:
o A process with multiple threads sharing an execution environment.
2. Heavyweight Process:
o Includes an execution environment and threads.
3. Lightweight Process:
o Refers to threads without an execution environment.

Key Insights

• Threads and execution environments together enable efficient concurrency.

• Modern operating systems have shifted to multi-threaded processes to address the
limitations of traditional process models.

Multi-Threaded Servers, Clients, and Threads vs. Processes

Architectures for Multi-Threaded Servers

 1. Worker Pool Architecture:
o Server creates a fixed number of worker threads during startup.
o An I/O thread receives requests, queues them, and workers process them.
o Advantages:
§ Allows prioritization with multiple queues.
o Disadvantages:
§ Inflexibility in handling high request rates.
§ High context-switching overhead between I/O and worker threads.
2. Thread-Per-Request Architecture:
o I/O thread spawns a new thread for each request, destroyed after processing.
o Advantages:
§ No contention for a shared queue.
§ Maximized throughput with no limit on worker threads.
o Disadvantages:
§ High overhead from frequent thread creation and destruction.
3. Thread-Per-Connection Architecture:
o Each connection has its own thread, destroyed upon connection closure.
o Advantages:
§ Lower thread-management overhead than thread-per-request.
o Disadvantages:
§ Potential delays if one thread handles multiple outstanding requests.
4. Thread-Per-Object Architecture:
o Each remote object has an associated thread and a per-object queue.
o Advantages:
§ Reduced thread-management overhead.
o Disadvantages:
§ Clients may experience delays due to uneven thread workloads.
5. Hybrid and Custom Architectures:
o Variations and hybrids of the above architectures address specific server
needs.

Threads in Clients

1. Threads enable clients to perform computation concurrently with remote method

invocations.
o Example: A client thread generates results while another thread handles
blocking remote calls.
2. Web browsers use threads to handle multiple concurrent requests for web pages,
reducing delays.

Threads vs. Processes

1. Advantages of Threads:
o Cheaper to create and manage than processes.
o Switching between threads in the same process is faster than between
processes.
o Threads share an execution environment, enabling efficient resource sharing.
2. Disadvantages of Threads:
o Threads within the same process are not protected from each other, posing
potential risks.
 3. Comparison of Resource Management:
o Execution Environment:
§ Includes address space, communication interfaces, open files, and
thread synchronization tools.
o Thread:
§ Has scheduling priority, execution state (e.g., BLOCKED,
RUNNABLE), saved processor registers, and interrupt handling state.
4. Execution environments and threads share address space, hardware cache, and
memory pages.

Key Insights

• Threads enhance concurrency and performance, especially in servers and clients.

• Threads are preferred over processes due to lower overhead and better resource-
sharing efficiency.

Operating System Architecture

Principles and Requirements of Open Distributed Systems

1. Openness:
o Run only necessary system software per computer to optimize memory usage.
o Allow independent software updates and changes for different services.
o Support multiple alternatives for the same service tailored to various users or
applications.
o Enable the addition of new services without compromising existing ones.
2. Separation of Mechanisms and Policies:
o Fixed resource management mechanisms are distinct from policies, enabling
flexibility across applications and services.
o Kernels ideally provide basic mechanisms for resource management, with
server modules dynamically loaded for specific policies.

Monolithic Kernels
 1. Characteristics:
o Large and integrated, performing all OS functions with megabytes of code.
o Non-modular, making adaptation to new requirements difficult.
o Includes server processes in the kernel address space.
2. Advantages:
o Efficient operation due to minimal overhead in invoking system functions.
3. Disadvantages:
o Lack of modularity, making maintenance and updates challenging.
o Limited support for extensibility and openness in distributed systems.

Microkernels

1. Characteristics:
o Minimal functionality in the kernel (e.g., address spaces, threads, IPC).
o All other services provided by dynamically loadable servers.
o Promotes modularity and extensibility through memory protection.
2. Advantages:
o Extensible and modular with smaller, less bug-prone kernels.
o Supports multiple OS emulations on the same platform.
3. Disadvantages:
o Performance cost due to overhead in interprocess communication.

Hybrid and Advanced Kernel Designs

1. Mach and Chorus:

o Original designs ran servers as user processes but later allowed kernel-space
servers for performance gains.
o Enabled debugging at the user level with performance optimization in the
kernel space.
2. SPIN:
o Single address space with type-safe language (Modula-3) ensuring protection.
o Uses event-based programming for interaction between modules.
 3. Nemesis:
o Single address space with restricted access based on protection attributes.
o Eliminates cache flushing during domain transitions.
4. L4 and Exokernel:
o L4: Second-generation microkernel focusing on user-space modules with
optimized IPC.
o Exokernel: Minimal kernel providing low-level resource allocation, with
applications managing resources via libraries.

Comparison of Kernel Types

1. Monolithic Kernels:
o Efficient but hard to adapt and maintain.
o Susceptible to bugs due to shared address space.
2. Microkernels:
o Modular and extensible but with performance overhead.
3. Hybrid Approaches:
o Aim to balance modularity with performance, but may introduce complexity
and risks.

Transition to Virtualization

• Virtualization now replaces microkernels as the primary innovation for supporting

multiple subsystems and enforcing protection.

Case Study: CORBA

Summary of the Object Management Group (OMG) and CORBA:

1. Formation and Purpose of OMG:

o Established in 1989 to promote distributed object systems.
o Aimed to leverage object-oriented programming and the growing adoption of
distributed systems.
o Advocated for open systems with standard object-oriented interfaces to
accommodate heterogeneous hardware, networks, operating systems, and
programming languages.
2. Goals of OMG:
o Enable distributed objects to be implemented in any programming language.
o Facilitate communication between distributed objects regardless of language
or system.
3. Object Request Broker (ORB):
o Acts as a mediator to help a client invoke a method on an object.
o Responsibilities:
§ Locating the object.
 § Activating the object (if necessary).
§ Communicating the client’s request to the object.
§ Relaying the object’s response to the client.
4. Case Study: CORBA (Common Object Request Broker Architecture):
o Focuses on the CORBA 2 specification.
o CORBA 3 introduced a component model.
5. Key Components of CORBA’s RMI Framework:
o IDL (Interface Definition Language):
§ Language-independent method definitions.
o Architecture
o CDR (Common Data Representation):
§ Describes external data formats.
§ Specifies formats for request-reply protocols and related messages.
o Standard Remote Object References:
§ Ensures consistency in identifying remote objects.

Architecture of CORBA

Purpose of CORBA Architecture:

o Supports the object request broker (ORB) role, enabling clients to invoke
methods on remote objects across diverse programming languages.
2. Static and Dynamic Invocations:
o Static Invocation: Used when the remote interface is known at compile time;
employs client stubs and server skeletons.
o Dynamic Invocation: Used when the remote interface is unknown at compile
time; relies on dynamic invocation mechanisms.
3. Main Components of CORBA Architecture:
o ORB Core:
§ Manages communication functionalities.
§ Offers operations for initialization, shutdown, string-object reference
conversions, and dynamic invocation argument handling.
o Object Adapter:
§ Bridges IDL interfaces and servant classes.
§ Tasks:
 § Creates and maintains remote object references.
§ Dispatches RMI requests via skeletons to servants.
§ Activates and deactivates servants.
§ Provides unique object names for CORBA objects.
o Portable Object Adapter (POA):
§ Ensures interoperability across ORBs from different developers.
§ Supports transient and persistent object references.
§ Allows policy specifications for threading, servant management, and
object references.
o Skeletons:
§ Generated by IDL compilers for server languages.
§ Dispatch requests to servants, handling argument unmarshalling and
response marshalling.
o Client Stubs/Proxies:
§ Generated by IDL compilers for client languages.
§ Marshal arguments and unmarshal responses for RMI requests.
o Implementation Repository:
§ Activates and locates servers on demand.
§ Maps object adapter names to file paths of object implementations.
§ Supports access control and fault tolerance via replication.
o Interface Repository:
§ Stores information about registered IDL interfaces (methods,
arguments, and exceptions).
§ Enables reflection for dynamic invocation scenarios.
o Dynamic Invocation Interface:
§ Allows clients to make dynamic invocations without precompiled
proxies.
§ Clients retrieve method details from the interface repository to
construct and send invocations.
o Dynamic Skeletons:
§ Accept invocations for CORBA objects with interfaces unknown at
compile time.
§ Analyze requests to identify target objects, methods, and arguments.
o Legacy Code:
§ Existing non-distributed code can be integrated into CORBA by
defining IDL interfaces and creating adapters and skeletons.
Distributed File System

A Distributed File System (DFS) is a specialized type of file system that manages and
provides access to files stored across multiple machines connected via a network. Unlike
traditional file systems that operate on a single device, a DFS aims to ensure a seamless and
unified experience, allowing users and applications to access files as if they were on a local
disk, regardless of their physical location in the network.

Distributed File System Requirements

1. Transparency:
o Access Transparency: Local and remote files accessed using the same
operations, enabling programs to work on both without modifications.
o Location Transparency: Uniform file name space, allowing file relocation
without changing pathnames.
o Mobility Transparency: Files can be moved without modifying client
programs or system tables.
 o Performance Transparency: Satisfactory performance under varying load
conditions.
o Scaling Transparency: Incremental growth to handle varying loads and
network sizes.
2. Concurrent File Updates:
o Prevents interference during simultaneous file accesses or modifications by
different clients.
o Implements concurrency control, often using advisory or mandatory
file/record-level locking.
3. File Replication:
o Multiple copies of a file at different locations enhance scalability and fault
tolerance.
o Limited replication via local caching is common, but full replication is less
prevalent.
4. Hardware and Operating System Heterogeneity:
o Interfaces should enable client and server software implementation across
diverse operating systems and hardware.
5. Fault Tolerance:
o Ensures service continuity despite client/server failures.
o Techniques include at-most-once or at-least-once invocation semantics and
stateless server designs.
o File replication improves resilience but is complex to implement.
6. Consistency:
o Conventional systems aim for one-copy update semantics, though delays in
update propagation can lead to deviations.
o Important for ensuring coherent views of replicated or cached files.
7. Security:
o Includes access control lists, client request authentication, digital signatures,
and optional encryption for secure communication.
8. Efficiency:
o Must provide comparable or superior facilities to local file systems in
performance and reliability.
o Modular architecture helps cater to clients with varying goals and needs.
9. Administrative Convenience:
o Tools and operations should simplify installation, maintenance, and
management for administrators.

Implementation Goals:

• Comparable performance and reliability to local file systems.

• Adaptability to evolving client requirements through a modular architecture.

File Service Architecture

A well-structured distributed file system separates file access concerns into three
components: Flat File Service, Directory Service, and Client Module, each with distinct
responsibilities and interactions. The system also supports unique file identifiers (UFIDs) for
efficient management and consistency.
1. Components of the Architecture

• Flat File Service:

o Manages operations on the contents of files.
o Uses Unique File Identifiers (UFIDs) to refer to files.
o Generates UFIDs when files are created and ensures their uniqueness across
the system.
o Supports operations such as:
§ Create: Creates a new file and generates its UFID.
§ Delete: Deletes a file.
§ Read/Write: Allows reading/writing file data using positional indices.
§ GetAttributes/SetAttributes: Access or modify file metadata
(e.g., permissions).
• Directory Service:
o Maps text-based file names to their corresponding UFIDs.
o Manages directories and their hierarchical structures (e.g., as in UNIX).
o Provides operations to:
§ Generate directories.
§ Add or retrieve file names and their UFIDs.
o Stores directory files within the flat file service.
• Client Module:
o Integrates operations from the flat file service and directory service into a
unified application programming interface.
o Emulates file operations of different operating systems (e.g., UNIX file
operations).
o Maintains network location information for file and directory servers.
o Implements client-side caching to enhance performance.

2. Key Features

• Unique File Identifiers (UFIDs):

o Long, globally unique identifiers used to reference files in a distributed
system.
o Ensure consistency and simplify file management.
 • Hierarchical Naming:
o Allows nested directory structures, enabling intuitive organization and access.
• Caching:
o Improves performance by storing recently accessed file blocks locally on the
client side.
• RPC Interface for Flat File Service:
o Provides operations for reading, writing, creating, deleting, and managing file
attributes.
o Exceptions are raised for invalid UFIDs or insufficient access rights.

This modular architecture ensures flexibility, scalability, and compatibility with various
operating systems, offering a robust solution for distributed file management.

Case Study: Sun Network File System

Overview

• NFS Protocol:
o OS-independent protocol for performing operations on remote file stores.
o Uses Sun's RPC system with UDP or TCP for communication.
o Compatible with UNIX but designed to support other operating systems.
• Server Module:
o Resides in the kernel of NFS server computers.
o Processes requests from clients and translates them into NFS protocol
operations.

Virtual File System (VFS)

• Provides access transparency, allowing local and remote file access without
distinction.
 • Acts as an interface layer between UNIX-independent NFS file identifiers and
internal UNIX file identifiers.
• Keeps track of mounted filesystems (local and remote) using:
o VFS structures: Map remote filesystems to local directories.
o v-nodes: Indicate whether a file is local or remote.
§ Local files: Reference to local file index (i-node in UNIX).
§ Remote files: File handle containing information to identify the file on
the server.
• File Handles:
o Opaque identifiers derived from i-node numbers, with additional filesystem
and generation fields to ensure uniqueness.
o Passed between clients and servers for file identification.

Client Integration

• NFS Client Module:

o Emulates UNIX file system semantics.
o Integrated with the UNIX kernel for:
§ Seamless access via UNIX system calls.
§ Shared caching of recently used blocks across processes.
§ Improved security by retaining encryption keys in the kernel.
o Collaborates with VFS to transfer and cache file blocks locally.

Access Control and Authentication

• Stateless Server:
o Does not maintain open file states; performs authentication on each request.
o Clients send user credentials (user ID and group ID) with each request.
o Permissions are verified against file attributes.
• Security:
o Vulnerable to impersonation in basic setups.
o Enhanced security options:
§ DES encryption for user authentication.
§ Integration with Kerberos for stronger authentication and security.

NFS Server Interface

• Provides operations for files and directories, integrating functionalities of the flat file
service and directory service models:
o File operations: read, write, getattr, setattr.
o Directory operations: create, remove, rename, mkdir, rmdir, readdir,
statfs, and more.
o Combines file creation and directory insertion in the create operation.

Mount Service

• Separate process for mounting remote filesystem subtrees by clients.

• Uses the /etc/exports file on servers to list local filesystems available for remote
mounting.
• Access lists specify which hosts can mount each filesystem.
Summary of NFS Design and Features

• Location and Access Transparency:

o NFS allows clients to access remote files using the same system calls as local
files, ensuring no modification of programs is needed.
o Remote filesystems are added to the client’s local namespace, allowing for
uniform access to remote files with proper configuration.
• Location Transparency:
o Each client determines where remote-mounted filesystems appear in its local
hierarchy.
o NFS does not enforce a network-wide file namespace, so remote file paths can
vary between clients, but a consistent namespace can be configured.
• Mobility Transparency:
o Filesystems can be moved between servers, but clients need to manually
update their mount tables to access files in new locations, so migration
transparency is not fully achieved.
• Scalability:
o NFS can scale to handle large real-world loads with additional processors,
disks, and servers.
o Performance can be limited by "hot spot" files that are accessed frequently,
necessitating the use of distributed systems like Coda or AFS for better
scalability.
• File Replication:
o NFS supports read-only file replication across servers but does not support
replication with updates.
o The Sun Network Information Service (NIS) supports the replication of simple
key-value databases, such as /etc/passwd and /etc/hosts.
• Hardware and OS Heterogeneity:
o NFS is implemented across a wide range of operating systems and hardware
platforms, supporting diverse filing systems.
• Fault Tolerance:
o The stateless nature of NFS allows clients to resume operations after server
failure, with minimal impact on file access.
o Client failure has no impact on the server, as the server does not maintain any
client-specific state.
• Consistency:
o NFS provides an approximation to UNIX-like one-copy semantics, suitable for
most applications, though it is not ideal for file sharing in closely coordinated
processes across machines.
• Security:
o NFS's security was improved with the integration of Kerberos and secure
RPC (RPCSEC_GSS) for better authentication and data privacy.
o Many installations still lack these security measures, leaving them insecure.
• Efficiency:
o NFS is highly efficient, evidenced by its widespread use in environments with
heavy loads, making it a popular and effective protocol for networked file
systems.