Distributed and Networked Operating Systems

Introduction and Context

A distributed system is a collection of independent computers that cooperatively provide services to users and applications. The computers communicate through a network, have separate memories, and may fail independently. A distributed operating system (DOS) attempts to manage these computers as an integrated computational environment, while a network operating system primarily provides communication and resource-sharing services while preserving the identity of individual machines.

Distributed and networked operating systems are fundamental to cloud computing, data centres, high-performance computing, peer-to-peer systems, mobile infrastructure, and large-scale artificial-intelligence platforms. They address a central problem: how can processes that execute on different machines coordinate reliably when communication is slower and less reliable than local memory access, and when there is no globally shared clock or memory?

The principal difficulty is that distributed systems must operate despite latency, message loss, machine failures, inconsistent observations, concurrency, and changing membership. This chapter develops the concepts and mechanisms used to address these difficulties.

Learning Objectives

By the end of this chapter, students should be able to:

• distinguish network operating systems from distributed operating systems;
• explain remote communication mechanisms and remote procedure calls;
• analyse distributed coordination, mutual exclusion, election, and consensus;
• explain physical and logical clock models and their limitations;
• describe naming, replication, consistency, and fault-tolerance techniques;
• compare distributed file systems and cluster architectures;
• interpret transparency models and their practical trade-offs;
• evaluate a distributed design using performance, reliability, consistency, and governance criteria.

1. Network Operating Systems and Distributed Operating Systems

A network operating system (NOS) supports communication and resource sharing among computers. Users commonly know which machine provides a service, and commands may explicitly identify remote resources. Examples include systems using network file shares, remote login, directory services, and network printing.

A distributed operating system seeks a stronger abstraction: a collection of machines appears to users and applications as one coherent system. Processes may be placed on different nodes, files may be replicated automatically, and the system may conceal the location or migration of resources.

The distinction is architectural rather than absolute. Modern cloud platforms combine NOS functions, distributed middleware, virtualisation, container orchestration, and storage services. Nevertheless, the following comparison is useful:

| Feature | Network operating system | Distributed operating system |

|---|---|---|

| Machine identity | Usually visible | Often hidden or abstracted |

| Resource access | Explicitly remote | May appear local |

| Process management | Mainly local | Can be global or coordinated |

| Failure model | Remote failure is visible | Attempts graceful masking or recovery |

| Main objective | Connectivity and sharing | Integrated system abstraction |

A distributed system is not simply a fast network. Local operations generally require memory access or system calls, whereas remote operations require message transmission, protocol processing, scheduling, and failure handling. Consequently, distributed software must be designed around partial failure and uncertainty.

2. System Models and Fundamental Assumptions

A distributed system is normally described using several models.

2.1 Communication model

Nodes exchange messages over channels. A channel may be reliable or unreliable, point-to-point or broadcast, ordered or unordered, and synchronous or asynchronous. In an asynchronous model, there is no known upper bound on message delay or process execution speed. This model is realistic but difficult because a silent process may be slow, disconnected, or crashed.

2.2 Failure model

Common failure types include:

• Crash failure: a process stops and performs no further actions.
• Omission failure: a process or channel fails to send or receive a message.
• Timing failure: a response occurs outside an expected time interval.
• Byzantine failure: a component behaves arbitrarily, potentially sending conflicting or malicious information.

A failure detector based only on timeouts cannot always distinguish a crashed process from a slow one. Therefore, many practical systems use suspicions rather than absolute conclusions.

2.3 Performance model

Important measures include latency, throughput, availability, scalability, and communication overhead. If a remote operation requires a request and response, its minimum communication component is approximately one round-trip time, excluding processing and queueing. This is not a universal execution-time formula; it is a lower-level timing decomposition under the assumption that one request and one response are necessary.

3. Remote Communication

3.1 Message passing

Message passing is the basic communication mechanism. A sender places data in a message and transmits it through the network; a receiver accepts and interprets it. Communication may be:

• Synchronous, where the sender or receiver waits for a matching operation;
• Asynchronous, where sending can continue after the message is handed to the communication system;
• Buffered, where messages are stored temporarily;
• Unbuffered, where sender and receiver must rendezvous.

Message formats should specify data types, encoding, byte order, version information, authentication context, and error semantics. Portable encodings such as Protocol Buffers, JSON, or carefully defined binary formats allow heterogeneous machines to communicate.

3.2 Remote procedure call

Remote procedure call (RPC) allows a client to invoke a procedure that executes on another machine. The client calls a local stub, which marshals arguments into a request. The server stub unmarshals the request, invokes the service, marshals the result, and sends a reply.

A typical RPC sequence is:

1. The client creates a request identifier and arguments.

2. The client stub serialises the request.

3. The transport sends the request to a server.

4. The server validates, authenticates, and executes it.

5. The server returns a result or error.

6. The client matches the reply with the outstanding request.

RPC semantics require care. “At-most-once” execution attempts to ensure that an operation executes no more than once, commonly using request identifiers and duplicate detection. “At-least-once” execution retries until a response is received, which can execute a non-idempotent operation more than once. An operation such as setting a value is usually idempotent; incrementing a counter is not unless protected by a transaction or unique-operation mechanism.

Timeouts are useful for responsiveness but do not prove that the server failed. Retries therefore require backoff, request identifiers, idempotence, and limits. A robust API exposes errors such as timeout, authentication failure, unavailable service, and rejected request rather than pretending that every failure is a normal application result.

3.3 Distributed communication patterns

Common patterns include request–reply, publish–subscribe, message queues, event streams, and multicast. Queues decouple producers from consumers and can absorb bursts, but they introduce issues involving ordering, duplication, retention, and back pressure. Publish–subscribe systems support multiple consumers but require subscription management and delivery guarantees.

4. Coordination and Distributed Agreement

Coordination is necessary when processes share resources, elect a leader, commit a transaction, or maintain a replicated state.

4.1 Distributed mutual exclusion

In a single machine, a lock can be implemented using shared memory and atomic instructions. In a distributed system, processes must exchange messages to determine who owns a resource.

A central coordinator algorithm is simple: a process requests a lock from the coordinator, waits for a grant, uses the resource, and sends a release. Its strengths are simplicity and low conceptual complexity. Its weaknesses are coordinator bottleneck and single-point failure.

A token-based algorithm grants access to the process holding a unique token. Mutual exclusion follows if the token is never duplicated. Token loss and recovery are difficult, however, and token circulation may waste communication when few processes need the resource.

A permission-based algorithm requires a process to obtain permission from other participants, often using timestamps to order requests. It can avoid a central coordinator but typically generates more messages and must recover from failed participants.

4.2 Leader election

Many distributed algorithms require a leader to sequence operations or coordinate recovery. Election algorithms select one process according to a rule such as the highest identifier among currently participating processes. An election must address stale information, simultaneous elections, network partitions, and rejoining nodes. A leader is not automatically correct merely because it has been elected; followers may need terms, leases, or quorum confirmation to prevent multiple leaders from acting concurrently.

4.3 Consensus

Consensus requires non-faulty processes to agree on a value despite failures. Its standard properties are:

• Agreement: non-faulty processes do not decide different values.
• Validity: the decided value is related to a value proposed by a process.
• Termination: non-faulty processes eventually decide, under the assumptions of the algorithm.

Practical consensus protocols, such as Raft and Paxos, replicate a log or state machine. A leader proposes entries, followers acknowledge them, and an entry becomes committed after sufficient agreement, commonly a quorum. The exact quorum rule depends on the membership and failure model. For a fixed group of an odd number of nodes, a majority is more than half; for example, a five-node group requires three acknowledgements for a majority. Consensus does not eliminate failures or network partitions; it defines which operations may safely proceed.

5. Time and Ordering in Distributed Systems

There is no universally shared physical clock. Even synchronised clocks differ because of clock drift, network delay, adjustment error, and imperfect synchronisation. Therefore, distributed systems distinguish physical time from event ordering.

5.1 Physical clocks

Protocols such as Network Time Protocol estimate clock offset and delay using timestamp exchanges. Physical clocks are useful for certificates, leases, monitoring, and human-readable logs, but a timestamp alone may not establish causal order.

5.2 Lamport logical clocks

A Lamport clock assigns an integer to events. Each process increments its clock before an event; when sending a message, it includes the clock value; when receiving a message with timestamp t, the receiver sets its clock to at least t plus one. If event a causally precedes event b, then the Lamport timestamp of a is less than that of b. The converse is not guaranteed: a smaller timestamp does not prove causality.

5.3 Vector clocks

A vector clock stores one logical counter for each relevant process. It can identify concurrency more precisely than a Lamport clock. If every component of vector V is less than or equal to the corresponding component of W, and at least one is strictly less, then V causally precedes W. If neither vector dominates the other, the events are concurrent. The cost is storage and communication overhead proportional to the number of tracked processes, which can be substantial in dynamic systems.

Ordering mechanisms support replicated databases, conflict resolution, distributed debugging, and event processing. They should not be confused with synchronising wall-clock time.

6. Naming and Discovery

Naming maps human- or application-level identifiers to resources such as hosts, services, files, users, or objects. A name service may be centralised, hierarchical, distributed, or replicated.

A good naming system provides location independence, scalability, fault tolerance, and efficient lookup. Hierarchical naming, as used by domain-name systems, divides responsibility across administrative zones. Service discovery systems maintain mappings between logical service names and currently available instances. They commonly use health checks, leases, registration expiry, and load-balancing policies.

Naming creates security obligations. A client must verify that the returned address represents the intended service. Authentication, authorisation, certificate validation, signed records, and protection against cache poisoning are essential. Stale discovery information can route requests to failed or decommissioned instances, so records require suitable time-to-live values and invalidation strategies.

7. Replication and Consistency

Replication stores multiple copies of data or service state. Its objectives include improved availability, reduced latency, load distribution, and disaster recovery. Replication also creates the problem of keeping copies sufficiently consistent.

7.1 Replication strategies

• Primary–backup: one primary accepts updates and sends them to backups. Failover requires selecting and validating a new primary.
• Chain replication: updates move through an ordered chain; reads may be served at a designated end. It offers clear update ordering but can be sensitive to chain membership.
• Quorum replication: reads and writes contact selected subsets of replicas. In a simple N-replica model, read quorum R and write quorum W are often selected so that R + W > N and W > N/2, ensuring read–write and write–write intersection. These conditions apply to a particular quorum design and do not by themselves guarantee application-level consistency.
• Multi-primary replication: several replicas accept writes. It improves locality and availability but requires conflict detection and resolution.

7.2 Consistency models

Linearizability makes each operation appear to occur atomically at one point between its invocation and response, preserving real-time order. It is intuitive but can require coordination and may reduce availability during partitions.

Sequential consistency requires that the result be equivalent to some single sequential order that preserves each process’s program order; it does not necessarily preserve real-time order across processes.

Causal consistency preserves the order of causally related operations while allowing concurrent operations to be observed in different orders.

Eventual consistency guarantees that replicas converge if updates stop and communication continues, but clients may temporarily observe older or conflicting values. Eventual consistency is often suitable for social feeds, caches, and some catalogue data, but not automatically for balances or safety decisions.

A design should specify which operations require strong guarantees and which can tolerate stale results. Consistency is a correctness property, not merely a performance setting.

8. Fault Tolerance and Recovery

Fault tolerance combines redundancy, detection, containment, recovery, and verification. A system should define its failure assumptions before selecting a protocol.

8.1 Redundancy and availability

Replicas, backup power, multiple network paths, and geographically separate sites reduce the effect of individual failures. Reliability is not simply obtained by adding copies: correlated failures, software defects, misconfiguration, and common power or network dependencies can defeat nominal redundancy.

Availability is often discussed as the proportion of time a service is operational. If a service has availability A, its unavailability fraction is 1 − A. For independent components in a serial dependency, overall availability is approximately the product of component availabilities. This approximation assumes independence and a service that is available only when every component is available; real systems often violate both assumptions.

8.2 Failure detection and recovery

Heartbeats, timeouts, leases, and health checks detect suspected failures. Recovery may involve restart, state reconstruction from a log, failover to a replica, reconfiguration, or rollback. Checkpointing periodically saves state so that a process can restart from a known point. Write-ahead logging records intended updates before applying them, allowing committed operations to be replayed after a crash.

8.3 Partitions and the CAP perspective

During a network partition, a system cannot guarantee unrestricted availability and strong consistency simultaneously for operations that require agreement across the partition. This observation is commonly summarised by the CAP theorem. CAP does not mean that a system can provide only two permanent properties, nor does it say that latency and consistency are irrelevant. It concerns the trade-off made when a partition occurs. Designers must identify which operations may reject requests, return stale data, or continue with weaker guarantees.

9. Distributed File Systems

A distributed file system (DFS) provides file storage across multiple machines while presenting a file-oriented interface. Major concerns include naming, metadata, block placement, caching, replication, recovery, and security.

A typical DFS separates metadata from file data. Metadata services manage names, directories, permissions, and block locations, while storage nodes hold file blocks. Large files are divided into blocks to enable parallel transfer and distributed storage. Replication protects against node failure and improves read locality.

Caching reduces latency and network traffic but creates coherence problems. A client may cache data and later read a stale copy. Possible policies include write-through caching, write-back caching, close-to-open consistency, leases, and explicit invalidation. The appropriate policy depends on workload and application expectations.

Metadata services may be centralised for simplicity, partitioned for scale, or replicated using consensus. A central metadata service can become a bottleneck or single point of failure unless it is protected by replication and recovery. Security requires authentication, authorisation, encryption in transit, encryption at rest where appropriate, audit trails, and careful management of administrative privileges.

10. Clusters and Resource Management

A cluster is a group of connected computers coordinated to provide computation, storage, or services. Clusters may be:

• High-performance clusters, which execute parallel scientific or engineering workloads;
• High-availability clusters, which provide failover and service continuity;
• Load-balancing clusters, which distribute requests across service instances;
• Storage clusters, which pool disks and nodes into a logical storage system.

Cluster managers schedule tasks, monitor health, place workloads, enforce resource limits, and recover failed tasks. Placement decisions consider CPU, memory, accelerator availability, data locality, network bandwidth, affinity, and anti-affinity. Containers and virtual machines improve isolation and portability, but they do not remove the need for operating-system scheduling, security boundaries, and failure handling.

AI workloads illustrate these issues. Training may distribute model computation across accelerator nodes, while parameter synchronisation or gradient exchange creates substantial network traffic. Data pipelines require consistent naming, replicated storage, and checkpoint recovery. A failed worker should not necessarily terminate a long-running job; task retry and checkpointing can reduce lost work. At the same time, repeated retries may amplify overload, so resource managers need backoff and admission control.

11. Transparency Models

Transparency describes which distributed-system details are hidden from users or programs. Important forms include:

• Location transparency: the name does not reveal where a resource resides.
• Migration transparency: a resource can move without changing its name.
• Replication transparency: users need not know how many copies exist.
• Concurrency transparency: simultaneous users are coordinated safely.
• Failure transparency: the system masks selected failures or presents recovery uniformly.
• Persistence transparency: users need not know whether data is in memory, disk, or another durable medium.
• Access transparency: local and remote resources are accessed through similar operations.

Transparency is valuable because it reduces application complexity. Complete transparency is neither possible nor always desirable. Remote access has latency, security, and failure characteristics that may matter to application logic. A system that hides all failures can cause indefinite waits or unsafe retries. Effective designs expose meaningful failure and consistency semantics while hiding unnecessary implementation details.

12. Applied Case: A Distributed University Learning Platform

Background

Consider an illustrative case in which a university operates a learning platform used for course content, assignment submission, grading, and examination delivery. Students access the platform from multiple regions, and demand increases sharply before deadlines.

Problem

A single application server causes slow responses and becomes a single point of failure. Assignment submissions must not be lost or duplicated. Course materials can tolerate brief staleness, but grades and submission receipts require stronger guarantees. The platform also stores personal data and examination materials.

Analysis

The workload contains different consistency requirements. Static course content can be cached and replicated. Submission metadata requires durable storage and an unambiguous submission identifier. The system must handle duplicate requests caused by browser retries, server timeouts, and temporary network failures. Service discovery is needed because application instances change as load varies.

Approach and solution

A load balancer distributes requests among stateless application instances. A replicated object-storage service holds uploaded files, while a transactional metadata service records the student, assessment, version, timestamp, and object identifier. Each submission request carries a unique client-generated or server-issued idempotency key. If the same key is received again, the service returns the original result rather than creating a second submission.

Course materials are served through caches with controlled expiration. Submission metadata is written using a quorum-backed or transactional replicated service. A consensus-based coordination service manages configuration and leader selection, but it is not used to store large files. Monitoring records latency, failure rate, queue depth, replica health, and unusual access patterns.

Encryption protects data in transit and at rest. Role-based authorisation separates students, instructors, exam administrators, and system operators. Audit logs record access to grades and examination content. Backups are tested through restoration exercises rather than merely being declared successful.

Outcome

The architecture scales application capacity horizontally, limits the effect of a failed instance, prevents duplicate submissions, and assigns different consistency policies to different data. It does not eliminate all risk: a regional outage, incorrect permissions, corrupted software release, or compromised administrator account remains possible. Multi-region recovery, immutable backups, change control, and incident response are therefore necessary.

Learning points

The case demonstrates that distributed design is a set of explicit trade-offs. Replication improves availability but creates consistency work. Retries improve resilience but require idempotence. Caching improves performance but can expose stale data. Transparency simplifies use, but important semantics such as durability, privacy, and failure must remain visible.

13. Design Challenges, Governance, and Best Practices

Distributed systems are difficult to test because timing and failures are nondeterministic. Testing should include delayed messages, duplicated messages, reordered messages, crashed nodes, expired leases, partial partitions, corrupted data, and clock skew. Fault-injection and controlled chaos testing can reveal assumptions that normal testing misses.

Security must be designed across trust boundaries. Mutual authentication, least privilege, key rotation, secure boot where appropriate, network segmentation, input validation, and tamper-evident logging are core controls. Personal and educational data may be subject to privacy and retention regulations. Replication across national borders can create legal obligations concerning data residency and access.

Best practices include:

1. define the failure and consistency model before choosing technologies;

2. distinguish idempotent from non-idempotent operations;

3. use deadlines, bounded retries, exponential backoff, and circuit breakers;

4. make request identifiers and correlation identifiers observable;

5. replicate critical state, but avoid unnecessary coordination;

6. document stale-data and failover behaviour;

7. separate control-plane metadata from bulk data paths;

8. test recovery, restoration, and reconfiguration regularly;

9. monitor saturation and queue growth, not only average latency;

10. preserve auditability, privacy, and least-privilege access.

Contemporary Developments

Modern distributed operating environments increasingly combine programmable networks, serverless execution, container orchestration, edge computing, and specialised accelerators. Edge systems reduce latency by placing computation near sensors or users, but they face intermittent connectivity, limited resources, and difficult update management. Serverless systems hide machine management but still expose cold-start latency, statelessness, quotas, and distributed tracing requirements.

Confidential computing uses hardware-supported isolation to protect data while it is processed, although it introduces attestation and key-management complexity. More systems use formal specifications, model checking, deterministic simulation, and eBPF-based observability to detect errors. AI-assisted operations can predict failures or optimise placement, but automated decisions must be explainable enough for operational review and must not weaken access control or accountability.

Chapter Summary

Distributed and networked operating systems coordinate independent computers connected by communication networks. Network operating systems emphasise connectivity and resource sharing, whereas distributed operating systems attempt to provide a unified abstraction. Remote communication uses message passing, RPC, queues, and event mechanisms, all of which must account for latency, retries, duplication, and partial failure.

Coordination mechanisms include distributed mutual exclusion, leader election, and consensus. Physical clocks cannot provide perfect global time, so Lamport and vector clocks represent causal ordering. Naming and service discovery map logical identifiers to changing resources and require security and freshness controls.

Replication improves performance and availability but creates consistency requirements. Linearizability, sequential consistency, causal consistency, and eventual consistency represent different guarantees. Fault tolerance depends on redundancy, failure detection, logging, checkpointing, recovery, and explicit handling of network partitions. Distributed file systems combine metadata management, block storage, caching, replication, and security. Clusters support scalable computation, high availability, load balancing, and AI workloads.

Transparency can hide location, migration, replication, concurrency, failure, persistence, and access details, but excessive transparency can conceal important latency, security, and correctness consequences. Effective distributed design therefore makes trade-offs explicit, tests failure conditions, and combines technical mechanisms with governance, privacy, and operational discipline.

Key Terms

Distributed system: A collection of independent computers that cooperate through communication.

Network operating system: An operating system that supports communication and resource sharing among networked machines.

Remote procedure call: A mechanism that allows a program to invoke a procedure executing on another machine.

Marshalling: Serialising arguments or results into a transmissible representation.

Idempotence: A property whereby repeating an operation has the same intended effect as performing it once.

Partial failure: A condition in which some components fail while others continue operating.

Distributed mutual exclusion: Coordinating processes so that only one may access a shared resource at a time.

Leader election: Selecting one process to coordinate distributed activity.

Consensus: Agreement among distributed processes on a value despite specified failures.

Lamport clock: A logical clock that represents causal precedence using ordered integers.

Vector clock: A vector of logical counters used to represent causality and concurrency.

Naming service: A service that maps logical names to resources or locations.

Replication: Maintaining multiple copies of data or service state.

Consistency model: Rules describing what values and operation order clients may observe.

Linearizability: A consistency guarantee in which operations appear atomic and respect real-time order.

Eventual consistency: A guarantee that replicas converge when updates stop and communication continues.

Distributed file system: A file system whose data and metadata are stored across networked machines.

Quorum: A subset of replicas whose agreement is required for an operation.

Transparency: The degree to which distribution-related details are hidden from users or programs.

Review Questions

Short Answer Questions

1. What is the principal difference between a network operating system and a distributed operating system?

2. Why can a timeout not prove that a remote process has crashed?

3. What problem does an idempotency key solve in an RPC-based service?

4. How does a vector clock improve on a Lamport clock?

5. Name two forms of transparency in a distributed system.

Long Answer Questions

1. Explain RPC processing from client invocation to reply, including marshalling, retries, duplicate requests, and failure semantics.

2. Compare central-coordinator, token-based, and permission-based distributed mutual-exclusion algorithms.

3. Explain primary–backup, quorum, and multi-primary replication and identify the consistency challenges of each.

4. Describe the role of metadata, blocks, caching, replication, and recovery in a distributed file system.

5. Explain how consensus, logging, checkpointing, and failover contribute to fault tolerance.

Analytical / Application Questions

1. Design a submission service for an online examination system. Specify its replication strategy, consistency requirements, retry policy, security controls, and recovery approach.

2. A five-node replicated service requires a majority to commit an update. How many acknowledgements are required, and what risks arise if the network divides into groups of two and three nodes?

3. A social-media feed tolerates stale reads, but account balances do not. Recommend consistency and replication approaches for each, and justify the difference using latency, availability, and correctness considerations.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a distributed operating system from a network operating system?

A. A distributed operating system attempts to present multiple machines as an integrated system.

B. A distributed operating system cannot use message passing.

C. A network operating system always provides stronger consistency than a distributed operating system.

D. A network operating system requires all machines to share physical memory.

Correct Answer: A. A distributed operating system attempts to present multiple machines as an integrated system.

Question 2

What is the main danger of retrying a non-idempotent remote operation after a timeout?

A. The operation may execute more than once.

B. The network automatically encrypts the request.

C. The server clock becomes synchronised.

D. The client loses all local memory.

Correct Answer: A. The operation may execute more than once.

Question 3

Which property is required by consensus?

A. Every process must remain available forever.

B. Non-faulty processes must not decide different values.

C. All messages must arrive in physical-time order.

D. Every process must have identical hardware.

Correct Answer: B. Non-faulty processes must not decide different values.

Question 4

What can a Lamport timestamp establish?

A. Exact physical time at another machine.

B. That a smaller timestamp always represents a causally earlier event.

C. Causal precedence when one event causally precedes another.

D. That two events with different timestamps are concurrent.

Correct Answer: C. Causal precedence when one event causally precedes another.

Question 5

If a replicated system has five nodes and requires a majority for an update, how many nodes must acknowledge the update?

A. One

B. Two

C. Three

D. Five

Correct Answer: C. Three

Question 6

Which consistency model guarantees that operations appear to occur atomically while respecting real-time order?

A. Eventual consistency

B. Causal consistency

C. Sequential consistency

D. Linearizability

Correct Answer: D. Linearizability

Question 7

What is the primary purpose of a distributed file-system metadata service?

A. To manage names, directories, permissions, and locations of file data.

B. To replace all data replicas with a single cache.

C. To eliminate the need for authentication.

D. To synchronise every user’s physical clock.

Correct Answer: A. To manage names, directories, permissions, and locations of file data.

Question 8

What does a network partition generally force a strongly consistent distributed service to consider?

A. Whether to reject some operations rather than continue inconsistently.

B. Whether to disable all encryption permanently.

C. Whether to convert every file into a local file.

D. Whether to remove all replicas.

Correct Answer: A. Whether to reject some operations rather than continue inconsistently.

Question 9

Which mechanism most directly helps recover committed state after a process crash?

A. Write-ahead logging

B. Randomised naming

C. Unbounded caching

D. Disabling checkpoints

Correct Answer: A. Write-ahead logging

Question 10

Why can complete transparency be undesirable in a distributed system?

A. It can conceal latency, failure, and consistency consequences that applications must handle.

B. It prevents any use of replication.

C. It guarantees that all operations are local.

D. It eliminates the need for resource names.

Correct Answer: A. It can conceal latency, failure, and consistency consequences that applications must handle.