1.

ISSUES IN DESIGNING A DISTRIBUTED OPERATING

SYSTEM
• The reasons are

o Transparency

o Reliability

o Flexibility

o Performance

o Scalability

o Heterogeneity

o Security

o Emulation of Existing Operating Systems

1. Transparency

• Make multiple computers appear as a single system (virtual uniprocessor).

• Support various forms of transparency, as per ISO standards:

o Access Transparency: Users access remote and local resources the same way.

o Location Transparency: Users access resources without knowing their

physical location.

o Replication Transparency: Multiple copies of resources are hidden from users.

o Failure Transparency: Mask partial system failures from users.

o Migration Transparency: Objects move without user awareness.

o Concurrency Transparency: Users feel they are the sole users of the system.

o Performance Transparency: System adapts to varying loads automatically.

o Scaling Transparency: System scales without affecting users.

2. Reliability

• Distributed systems should be more reliable than centralized ones.

• Requires effective fault-handling mechanisms:

o Fault Avoidance: Minimize faults through design.

o Fault Tolerance: Continue functioning during partial failures using:

 ▪ Redundancy techniques

▪ Distributed control

o Fault Detection and Recovery: Identify and correct system failures using:

▪ Atomic transactions

▪ Stateless servers

▪ Acknowledgements and timeout-based retransmissions.

3. Flexibility

• Design should allow ease of modification and enhancement for open distributed
systems.

4. Performance

• Distributed systems must perform at least as well as centralized ones.

• Design principles for performance improvement:

o Batch processing

o Caching

o Minimize data copying

o Minimize network traffic

o Use fine-grain parallelism for multiprocessing.

5. Scalability

• System should adapt to increased load and growth without significant disruption.

• Design guidelines:

o Avoid centralized entities and algorithms.

o Perform operations on client workstations.

6. Heterogeneity

• Challenges arise with different hardware and software systems in distributed setups.

• Heterogeneous systems are preferred for flexibility but require careful design.

7. Security

• Protect resources against destruction and unauthorized access.

• Additional requirements due to insecure networks:

 o Ensure message authenticity and integrity using cryptography.

8. Emulation of Existing Operating Systems

• For commercial success, new distributed operating systems should emulate existing
ones (e.g., UNIX).

• Allows new and existing software to run simultaneously, enabling easy migration.

2. What is distributed Computing System and it’s Models.

A Distributed Computing System is a network of multiple interconnected processors
or computers that work together to achieve a common goal. Rather than relying on a single
high-speed processor, the system distributes tasks and processes across multiple processors,
which communicate and coordinate with each other over a network. These advancements are
made possible due to improvements in microelectronic technology (leading to faster, more
affordable processors) and communication technology (resulting in efficient and cost-effective
computer networks). The goal is to increase efficiency, reliability, and performance through
parallel processing and resource sharing.

Models.
o Minicomputer Model

o Workstation Model

o Workstation Server Model

o Processor Pool Model

o Hybrid Model

1. Minicomputer Model

• Extension of the centralized time-sharing system.

• Comprises a few minicomputers or supercomputers connected via a network.

• Each minicomputer supports multiple users through interactive terminals.

• Users can access remote resources across the network.

• Example: The early ARPAnet.

2. Workstation Model

• Consists of several workstations interconnected by a high-speed LAN.

• Each workstation is a single-user computer with its own disk.

• Utilizes idle workstations to process jobs from other users when their own workstations
lack sufficient power.

• Issues to address:

1. Finding idle workstations.

2. Transferring processes between workstations.

3. Managing remote processes when users log onto previously idle workstations.

• Approaches for the third issue:

1. Allow remote process sharing resources with the logged-on user.

2. Terminate the remote process (risk of data loss).

3. Migrate the remote process back to its home workstation.

3. Workstation Server Model

• Users log onto their "home" workstation, with normal computations performed locally.

• Special servers (e.g., file or database servers) handle service requests.

• Advantages:

1. Cheaper to use a few minicomputers with large disks than many small diskful
workstations.

2. Easier maintenance and software updates with fewer disks and servers.

3. Users can access files uniformly regardless of the workstation.

4. No need for process migration as services are accessed through client-server

communication.

5. Guaranteed response time as remote processes are not executed on

workstations.

4. Processor Pool Model

• Suitable when users occasionally require high computing power.

• Processors are pooled and shared on a demand basis, managed by a special run server.

• Users access the system from network-attached terminals (e.g., diskless workstations).

• There is no concept of a "home" machine; users log onto the system as a whole.
 5.

Hybrid Model
• Combines the workstation server model with the processor pool model.
• Ideal for environments with both interactive and computation-intensive tasks.
• Adds a processor pool to the workstation server model for large computations.
• Ensures efficient execution of computation-intensive jobs while guaranteeing
response time for interactive tasks.
• More expensive to implement than the other models.

3. What is consistent ordering of message? Give a protocol for

consistent ordering
Consistent ordering, or total order semantics, ensures that all messages are
delivered to all receiver processes in the same order, regardless of the order in which they were
sent. This approach provides a uniform view of the sequence of messages across all processes,
which is crucial for many distributed systems. Unlike absolute ordering, which relies on
globally synchronized clocks, consistent ordering is achieved using algorithms that ensure
agreement among processes.
ABCAST Protocol (for Consistent Ordering)

The ABCAST protocol is a distributed method used for consistent ordering of messages that
avoids the single point of failure issue associated with sequencer-based methods. Here's how
the ABCAST protocol works:

1. Message Sending

o The sender assigns a temporary sequence number to the message, ensuring it is

larger than any previous sequence number it used. A simple counter can track
and assign these numbers.

o The message is sent to all members of the multicast group.

3. Final Sequence Number

o The sender collects all proposed sequence numbers from group members and
selects the largest one as the final sequence number for the message.

o The sender then sends a commit message with the chosen final sequence number
to all members, ensuring its uniqueness due to the term i/Ni/Ni/N used in the
calculation.

4. Commitment and Message Delivery

o On receiving the commit message, each member attaches the final sequence
number to the message.

o The committed messages are delivered to the application programs in the order
of their final sequence numbers.

This protocol ensures that all messages are processed consistently and in the same order by all
members of the group.
4. What is DCE? Explain the DCE components and DCE cells.
DCE (Distributed Computing Environment) is a software framework developed by
the Open Software Foundation (OSF) to facilitate the creation and management of distributed
computing systems. It integrates various tools and services, originally developed by
universities and industries, into a cohesive package that supports interoperability and
distributed computing capabilities.

COMPONENTS:

1. Threads Package:

o Provides a model for building concurrent applications.

o Includes operations to create and manage multiple threads within a process and
synchronize access to shared data.

2. Remote Procedure Call (RPC) Facility:

o Essential for building client-server applications, forming the basis of

communication in DCE.

o Network and protocol-independent, offers secure client-server communication,

and automatically handles data conversion for clients and servers.

3. Distributed Time Service (DTS):

o Synchronizes clocks across computers within the system and with external
sources like the U.S. National Institute for Standards and Technology (NIST).

o Enables synchronization between different distributed environments.

4. Name Services:

o Includes the Cell Directory Service (CDS), Global Directory Service (GDS),
and Global Directory Agent (GDA).

o Facilitates loc+ation-transparent naming and access of resources (servers, files,

devices, etc.).

5. Security Service:

o Provides tools for authentication and authorization to secure resources against

unauthorized access.

6. Distributed File Service (DFS):

o Offers a systemwide file system with location transparency, high performance,

and availability.
 o Capable of serving clients of other file systems.

CELLS:
1. Purpose:
o Machines used by users working on a common goal should be placed in the
same cell.
o There are two approaches:
▪ Product-oriented: Separate cells for each product, covering all
activities (design, manufacturing, etc.) for that product.
▪ Function-oriented: Separate cells for each function (e.g., design),
regardless of the product.
2. Administration:
o Each cell has an administrator responsible for user registration and access
management.
o Grouping machines and users known to and manageable by a single
administrator in the same cell simplifies management tasks.
3. Security:
o Machines whose users have a higher level of trust in each other should be
placed in the same cell.
o Cell boundaries act as firewalls, requiring stricter authentication for accessing
resources across cells.
4. Overhead:
o DCE operations like name resolution and user authentication are more
efficient within the same cell.
o Machines that frequently interact and access common resources should be in
the same cell to minimize cross-cell operations and improve performance.
5. Explain the absolute ordering, consistent ordering and casual
ordering of messages. Give a mechanism to implement each one.
1.Absolute Ordering:

• Definition: Ensures that all messages are delivered to all receiver processes in the exact
order in which they were sent.

• Implementation: Utilizes global timestamps as message identifiers, requiring

synchronized clocks across machines. When a sender sends a message, the current
clock value (timestamp) is embedded in the message.

• Delivery Mechanism: Messages are saved in a queue at each receiver, and a sliding-
window mechanism periodically delivers messages whose timestamps fall within a
specified time window.

• Consideration: The window size should accommodate the maximum time required for
messages to travel across the network.

2. Causal Ordering:

• Definition: Allows for weaker semantics where messages can be delivered out of order
as long as causally related messages are delivered in the correct order. If two events are
causally related, they must be delivered in the order of their sending.

• Implementation: CBCAST protocol, which involves:

1. Each member maintains a vector indicating the last message received from each
member.

2. To send a message, the process increments its own vector component and
includes the vector in the message.

3. Upon receiving a message, the runtime checks two conditions:

 ▪ The sender’s last sent message is the next in sequence for the receiver.

▪ The sender has not received any messages the receiver hasn't.

4. If both conditions are satisfied, the message is delivered; otherwise, it is

buffered until conditions allow for delivery.

6. What are the desirable features of a good message passing system?

Explain.
1. Simplicity:
• A message-passing system should be straightforward and easy to use, allowing
programmers to construct new applications and communicate with existing ones with
minimal complexity.
• The system should provide clean and simple semantics that facilitate the development
of distributed applications without needing to manage underlying system or network
complexities.
2. Uniform Semantics:
• The semantics for remote communication should closely resemble those of local
communication to ensure ease of use.
 • This uniformity helps streamline the development process for applications that might
involve both types of communication.
3. Efficiency:
• Efficiency is critical; an inefficient message-passing system can make interprocess
communication prohibitively expensive.
• To optimize efficiency, a message-passing system should aim to:
o Reduce the number of message exchanges.
o Avoid the overhead of establishing and terminating connections for each
message exchange.
o Minimize connection maintenance costs.
o Implement piggybacking of acknowledgments with subsequent messages.
4. Reliability:
• A reliable message-passing protocol can handle failures, ensuring message delivery
despite interruptions caused by node crashes or communication link failures.
• Key mechanisms include:
o Acknowledgments and retransmissions based on timeouts for lost messages.
o Detection and handling of duplicate messages through sequence numbering.
5. Correctness:
• Correctness is especially important for group communication protocols, ensuring that:
o Atomicity: Messages sent to a group are delivered to all members or none at
all.
o Ordered Delivery: Messages arrive at receivers in an acceptable order.
o Survivability: Messages are delivered correctly despite partial failures in
processes, machines, or communication links.
6. Flexibility:
• The message-passing system must accommodate varying degrees of reliability and
correctness, depending on the specific application needs.
• Users should be able to choose and specify the types and levels of requirements,
allowing for both synchronous and asynchronous communication.
7. Security:
• A good message-passing system should ensure secure end-to-end communication,
protecting messages from unauthorized access during transit.
• Security measures include:
o Authentication of both sender and receiver.
o Encryption of messages before transmission.
8. Portability:
• The message-passing system should be designed to be portable, allowing for the
construction of new IPC facilities on different systems by reusing existing designs.
 • Applications developed using the message-passing system should also be portable,
requiring considerations for heterogeneity and possibly using an external data
representation format for communication between different architectures.

7. In a multigram communication, how can a recipient organize and

arrange datagram of same message? How does it recognize the loss
of messages?
In a multidatagram communication, where messages exceed the Maximum Transfer
Unit (MTU) and are split into multiple packets (datagrams), the recipient must effectively
organize and arrange these datagrams to reconstruct the original message accurately. The
following mechanisms are typically involved:
1. Sequential Numbering:
o Each datagram is assigned a sequence number by the sender before
fragmentation. This sequence number indicates the order in which the
datagrams should be assembled at the recipient's end. For example, if a message
is split into three datagrams, they may be numbered as 1, 2, and 3.
2. Header Information:
o Each datagram includes header information, which contains the sequence
number, total number of fragments, and possibly a message identifier. This
header helps the recipient identify and organize the datagrams correctly.
3. Reassembly Buffer:
o The recipient maintains a reassembly buffer that temporarily holds incoming
datagrams until all fragments of a message are received. As each datagram
arrives, the recipient checks the sequence number and stores it in the correct
position within the buffer.
4. Timeouts and Retransmissions:
o If the recipient does not receive all datagrams within a specific timeframe, it
may trigger a timeout mechanism. This mechanism can initiate a request for
retransmission of missing datagrams.
Recognition of Message Loss
Recognizing lost messages is a critical aspect of ensuring reliable communication in
multidatagram environments. The following strategies are commonly employed:
1. Acknowledgment System:
o The recipient can send acknowledgment messages (ACKs) back to the sender
for each successfully received datagram. If the sender does not receive an
acknowledgment for a specific datagram within a designated timeout period, it
assumes that the datagram was lost and can retransmit it.
2. Negative Acknowledgments (NAKs):
o Alternatively, the recipient can use negative acknowledgment messages to
inform the sender of specific datagrams that were not received. This approach
allows the sender to quickly retransmit only the missing datagrams rather than
all datagrams.
 3. Sequence Number Monitoring:
o As the recipient organizes the datagrams, it continuously monitors the sequence
numbers. If it detects a gap in the sequence (e.g., receiving datagrams 1 and 3
but not 2), it can infer that a datagram has been lost.
4. Integrity Checks:
o Each datagram may include checksums or hash values to verify the integrity of
the data. If a datagram arrives with an invalid checksum, it can be discarded,
and the sender can be prompted to retransmit it.

8. Differentiate between the stateful and stateless servers. Why do

distributed applications use stateless servers?
Why Stateless Servers?

1. Failure Recovery:

o Stateful servers lose state information upon crashes, potentially leading to

inconsistent results.

o Clients of stateful servers must implement complex error handling to detect

server crashes.

o Stateless servers allow clients to simply retry requests without needing to know
about server status.

2. Simplified Client Logic:

o Clients do not need to track state information, making their design simpler.

o Error handling is easier since clients can reissue requests without worrying
about server state.

3. Ease of Crash Recovery:

o Stateless servers enable straightforward recovery from failures due to the

absence of state reliance.

o No complex state restoration processes are required after a crash.

4. Scalability:

o Stateless servers can handle more requests without managing client state,
improving load distribution.

o Easier scaling in distributed systems due to simplified server design.

5. Flexibility:

o Stateless architectures allow for easier replication and load balancing of

services.

o Any server can handle requests from any client, improving performance and
reliability.

6. Application Dependency:

o The choice between stateless and stateful servers depends on the specific
requirements of the application.

o Designers must evaluate the advantages and disadvantages of both approaches

to make an informed decision.
9. List and explain the eight forms of transparency identified by ISO
for open distributed systems.
1. Access Transparency

• Users should not distinguish between local and remote resources.

• The operating system must manage resource location and servicing.

• Requires a well-designed set of system calls and a global resource naming facility.

2. Location Transparency

• Name Transparency: Resource names should not indicate their physical location.
Names must remain unique systemwide.

• User Mobility: Users can access resources with the same name regardless of the
machine they are using.

3. Replication Transparency

• Users should not be aware of multiple copies of resources.

• The system must manage naming and mapping of resource replicas automatically.

• Replication decisions (number of copies, placement, creation/deletion) are handled

transparently.

4. Failure Transparency

• Masks partial failures from users, allowing continued system functionality.

• Users should not notice failures except for possible performance degradation.

• Complete failure transparency is challenging and often impractical to achieve.

5. Migration Transparency

• Objects can be moved between nodes without user awareness.

• Migration decisions should be automated, and object names must remain unchanged.

• Interprocess communication should ensure messages reach migrating processes.

6. Concurrency Transparency

• Allows multiple users to share resources without awareness of each other.

• Event-ordering Property: Ensures consistent view for all users.

• Mutual-exclusion Property: Only one process can access a shared resource at a time.

• No-starvation Property: Ensures all requests for resources will eventually be granted.
 • No-deadlock Property: Prevents situations where processes block each other.

7. Performance Transparency

• The system should automatically reconfigure to optimize performance.

• Intelligent resource allocation and process migration are essential.

8. Scaling Transparency

• Allows the system to expand without disrupting user activities.

• Requires open-system architecture and scalable algorithms.

10. Explain implicit and explicit process addressing along with the
primitives used.
 11) What si Idempotency? How duplicate request messages are handled? (4)

Idempotency and Handling Duplicate Request Messages:

1. Definition of Idempotency:
Idempotency refers to an operation that produces the same result no matter how many times it is performed
with the same input or arguments. There are no unintended side effects from repeating the operation.
Example: A function like GetSqrt(64) always returns 8, no matter how many times it is called.
2. Non-Idempotent Operations:
Non-idempotent operations, on the other hand, produce different results if executed multiple times with the
same input. For example, debiting an account multiple times reduces the balance incorrectly.
Example: A server process that debits money from a bank account is non-idempotent because multiple
executions with the same request (due to network failures or timeouts) could result in an incorrect balance.
3. Handling Duplicate Requests with Timeout:
When a client doesn’t receive a response from a server (due to network issues or timeouts), it may resend the
request. This could lead to the server processing the same request multiple times, which is problematic for
non-idempotent operations like debiting money from an account.
4. Exactly-Once Semantics:
To avoid incorrect behavior, "exactly-once" semantics can be implemented. This ensures that even if a request
is sent multiple times, the operation is executed only once. One common way to implement this is by:
o Using unique identifiers for each client request.
o Maintaining a reply cache on the server to store the results of previously processed requests.
If a duplicate request is detected (based on the identifier), the server retrieves the stored result from the cache
and sends it to the client without reprocessing the request.
 12) Explain in brief any two commonly used semantics for ordered delivery of multicast messages (8)

1. Absolute Ordering

Definition:
Absolute ordering ensures that all messages are delivered to every receiver in the exact order they were sent,
maintaining a global sequence across the entire system.

Key Characteristics:

• Global Sequence: Every message is assigned a unique timestamp or sequence number that reflects the exact
order of sending.
• Clock Synchronization: Requires synchronized clocks across all participating machines to maintain the
global order.
• Implementation Method:
o Global Timestamps: Each message is tagged with a timestamp from a synchronized clock.
o Sliding-Window Mechanism: Receivers use a window to buffer incoming messages and deliver them in the
correct order based on their timestamps.
• Pros:
o Simple to understand and implement in systems with well-synchronized clocks.
o Guarantees a single, consistent order of message delivery across all receivers.
• Cons:
o Synchronizing clocks across distributed systems can be challenging and resource-intensive.
o Not flexible for applications that do not require a strict global order.

Use Case Example:

In a distributed database system where transactions must be applied in the exact order they were initiated to
maintain consistency.

2. Causal Ordering

Definition:
Causal ordering ensures that messages are delivered in an order that respects the causality of events. If one
message causally affects another, the affected message is delivered after the causing message. However,
messages that are not causally related can be delivered in any order.

Key Characteristics:

• Happened-Before Relationship: Uses the concept of causality to determine the order of message delivery.
• Vector Clocks: Each process maintains a vector clock to track the causal relationships between messages.
• Implementation Method:
o Vector Clocks: Each message carries a vector timestamp indicating its causal dependencies.
o Buffering Mechanism: Receivers buffer messages until all causally preceding messages have been delivered.
• Pros:
o More efficient than absolute ordering as it allows for parallelism where causality is not a concern.
o Reduces the overhead of maintaining a global order, improving performance in many scenarios.
• Cons:
o More complex to implement due to the need for maintaining and comparing vector clocks.
o May require additional memory and processing to manage buffered messages.

Use Case Example:

In collaborative applications like shared document editing, where updates that do not interfere with each other
can be applied in any order, but dependent updates must follow a specific sequence.
 13) Discuss tightly coupled and loosely coupled system. (6)

1. Tightly Coupled Systems

Definition:
In tightly coupled systems, all processors share a common primary memory (address space), and
communication between processors typically occurs through this shared memory.

Key Characteristics:

• Shared Memory: Processors communicate by reading and writing to a single, system-wide memory.
• Synchronous Processing: Processors usually work closely together in a synchronized manner.
• Low Communication Overhead: Since communication happens through shared memory, the delay in
communication is minimal.
• Physical Proximity: The processors are typically located close to each other, as the system relies on fast
access to shared memory.
• Limited Scalability: As the number of processors increases, the shared memory can become a bottleneck,
limiting scalability.

Use Case Example:

Parallel processing systems such as multi-core processors in a single machine, where tasks are distributed
across cores but share the same memory.

2. Loosely Coupled Systems

 Definition:
In loosely coupled systems, each processor has its own local memory, and communication between processors
is achieved by passing messages over a communication network.

Key Characteristics:

• Local Memory: Each processor has its own memory, and changes to one processor's memory are not visible
to others.
• Asynchronous Processing: Processors work independently and do not need to be tightly synchronized.
• Message Passing: Communication between processors occurs through messages, introducing network
latency.
• Greater Physical Separation: Processors can be distributed over wide geographical areas.
• High Scalability: Loosely coupled systems can scale to a large number of processors without significant
bottlenecks, as each processor operates independently.

Use Case Example:

Distributed systems such as cloud computing environments, where each node or machine has its own memory,
and tasks are distributed across a network.

14. How synchronization is carried out in interprocess communication (8)

Synchronization in Interprocess Communication (IPC)

 Synchronization in IPC ensures that multiple processes coordinate their actions when sending and receiving
messages. This coordination is crucial to maintain data consistency, prevent race conditions, and ensure
orderly communication. Below are the key mechanisms and concepts involved in synchronization within IPC:

1. Blocking vs. Nonblocking Primitives:

o Blocking Primitives:
▪ Send: The sending process is blocked until the receiver acknowledges receipt of the message.
▪ Receive: The receiving process is blocked until a message arrives.
▪ Effect: Ensures synchronization by making the sender and receiver wait for each other, promoting orderly
communication.
o Nonblocking Primitives:
▪ Send: The sending process proceeds immediately after copying the message to a buffer, without waiting for
acknowledgment.
▪ Receive: The receiving process continues execution and later checks if a message has arrived.
▪ Effect: Increases concurrency and efficiency by allowing processes to perform other tasks while
communication occurs.
2. Synchronous vs. Asynchronous Communication:
o Synchronous Communication:
▪ Both send and receive operations are blocking.
▪ Characteristics: The sender waits for the receiver to be ready, ensuring that messages are delivered only
when both parties are synchronized.
▪ Pros: Simplifies synchronization and ensures reliability, as the sender knows the message has been received.
▪ Cons: Can lead to reduced concurrency and potential deadlocks if not managed carefully.
o Asynchronous Communication:
▪ Either send or receive operations are nonblocking.
▪ Characteristics: Processes can continue execution without waiting, allowing for higher concurrency.
▪ Pros: Enhances performance and scalability by decoupling sender and receiver.
▪ Cons: Requires additional mechanisms to handle message delivery confirmation and ordering.
3. Message Buffering:
o Buffers: Temporary storage areas where messages are held before being processed.
o Role in Synchronization: Allows senders to proceed without waiting (in nonblocking sends) and receivers to
retrieve messages when ready.
o Types:
▪ Single Buffer: Holds one message at a time, potentially causing senders to block if the buffer is full.
▪ Multiple Buffers: Can hold multiple messages, reducing the likelihood of senders being blocked.
4. Polling vs. Interrupts for Message Arrival:
o Polling:
▪ The receiving process periodically checks (polls) the message buffer to see if a new message has arrived.
▪ Pros: Simple to implement.
▪ Cons: Can be inefficient as it consumes CPU cycles even when no messages are present.
o Interrupts:
▪ The system notifies the receiving process via a software interrupt when a new message arrives.
▪ Pros: More efficient as it eliminates unnecessary polling, allowing the process to perform other tasks until
notified.
▪ Cons: Can complicate programming due to the need to handle asynchronous events.
5. Conditional Receive Primitives:
o Definition: Nonblocking receive operations that immediately return control to the process, indicating whether
a message was received or not.
o Usage: Allows processes to attempt receiving messages without getting blocked, enabling them to perform
alternative actions if no message is available.
6. Timeout Mechanisms:
o Purpose: Prevent processes from being blocked indefinitely in scenarios where messages are lost or
senders/receivers crash.
o Implementation:
▪ Send Timeout: The sending process waits for a specified interval for an acknowledgment before aborting the
send operation.
▪ Receive Timeout: The receiving process waits for a specified interval for a message before proceeding or
handling the timeout event.
o Benefits: Enhances robustness and fault tolerance by allowing processes to recover from communication
failures.
7. Synchronous Communication Example:
o Process Flow:
1. Sender: Executes a blocking send operation and waits for acknowledgment.
2. Receiver: Executes a blocking receive operation and waits for the message.
3. Synchronization: Once the receiver gets the message, it sends an acknowledgment, allowing the sender to
resume execution.
o Illustration: Ensures that the sender knows the message has been successfully received before continuing.
8. Handling Communication Failures:
o Scenarios: Node crashes, network failures, lost messages.
o Strategies:
▪ Retries: Attempt to resend messages after a failure is detected.
▪ Error Handling: Use timeout values to detect failures and execute appropriate error-handling routines.
▪ Consistency Maintenance: Ensure that processes can recover to a consistent state despite communication
disruptions.
15) Describe blocking and non-blocking types of Inter-Process communication. (4)

Same as previous

16) What is stub? how are stubs generated? Explain how the use of stubs helps in making an RPC
mechanism transparent. (8)

What is a Stub?

A stub is a piece of code that acts as an intermediary for remote procedure calls (RPC). It allows a program to
execute a procedure on another system without the programmer having to explicitly manage the complexities
of network communication. A client stub represents the interface between the client and the RPC mechanism,
while a server stub serves the same role for the server. The primary function of stubs is to provide a normal
procedure call interface, making the RPC mechanism transparent to users.
 How are Stubs Generated?

Stubs can be generated in two main ways:

1. Manually: The RPC implementor writes custom translation functions to convert procedure arguments and
return values for communication between client and server.
2. Automatically: A more common approach, where an Interface Definition Language (IDL) is used to define
the client-server interface. The IDL compiler generates the client and server stubs based on this definition,
along with any necessary marshaling and unmarshaling operations (handling data formatting for
transmission).

Use of Stubs in RPC Transparency

Stubs play a crucial role in making the RPC mechanism transparent in the following ways:

1. Hiding Network Details: The client and server stubs handle the transmission of data between the client and
server, abstracting the network communication details from both sides. The programmer writes code as if
calling a local procedure, but in reality, the stub manages the remote call, making the network interactions
invisible to the user.
2. Marshaling and Unmarshaling: Stubs perform marshaling (packing of arguments into a message) and
unmarshaling (unpacking results from a message), which allows seamless transfer of data across systems. This
ensures that the data is transmitted correctly, regardless of where the client and server are located.
3. Error Handling: Stubs often handle retransmissions, acknowledgments, and error checks (like timeouts) in
the communication process, simplifying the error management for the client and server.
 In essence, by using stubs, the complex networking operations involved in remote communication are
abstracted away, allowing the programmer to write code as if the procedure is being executed locally. This
enhances ease of use and promotes transparency in the RPC mechanism.

17) Why do RPC systems support

call-by-value semantics for parameter passing? Explain.

RPC systems support call-by-value semantics for parameter passing primarily because it ensures
simplicity and reliability in remote procedure calls, particularly when dealing with distributed systems.
Here’s why:

1. Isolation Between Client and Server: In call-by-value, all parameters are copied into a message and sent
from the client to the server. This creates a clear separation between the client and server memory spaces,
avoiding issues that might arise from sharing references or pointers across different systems, which might not
have access to each other’s memory.
2. Ensures Data Consistency: When parameters are passed by value, the server works with a copy of the data,
ensuring that the original data on the client side remains unchanged. This reduces the complexity of managing
data integrity and prevents accidental modifications to client data by the server.
3. Network Transparency: In distributed systems, call-by-value simplifies the network communication
process. Only the values are transmitted, avoiding the complications of trying to share memory references
across different machines with potentially different architectures or operating systems.
4. Encourages Efficient Interface Design: Since passing large data by value can be costly (in terms of
bandwidth and transmission time), RPC systems using call-by-value semantics encourage users to optimize
the client-server interface. By making users aware of the overhead involved, it promotes careful design
decisions, reducing unnecessary data transmission and improving the overall efficiency of the RPC system.
 Thus, while call-by-value can be inefficient for large datasets, it provides simplicity, consistency, and
transparency in most common use cases, which is why it is often supported in RPC systems.

18) Explain two types of messages involved in the implementation of an RPC system. (8)

1. Call Messages

Purpose:
Call messages are used by the client to request the execution of a remote procedure on the server. They initiate
the RPC process by conveying the necessary information for the server to perform the desired operation.

Key Components:

• Remote Procedure Identifier:

o Function: Specifies the exact procedure that the client wants the server to execute.
o Details: Includes information such as the remote program name, version, and procedure number.
• Arguments:
o Function: Contains the input parameters required by the remote procedure.
o Details: These parameters are the data that the remote procedure will process.
• Message Identification Field (Sequence Number):
o Function: Uniquely identifies each call message.
o Details: Helps in detecting lost or duplicate messages, especially in scenarios involving system failures. It
also aids in matching reply messages to their corresponding call messages.
• Message Type Field:
o Function: Distinguishes call messages from reply messages.
o Details: For instance, this field might be set to 0 for call messages.
• Client Identification Field:
o Function: Identifies the client making the RPC request.
o Details: Used by the server to send the reply back to the correct client and to authenticate the client's request.

Process Flow:

1. Client Invocation:
The client initiates an RPC by calling a local stub procedure, which behaves like a normal procedure call.
2. Marshaling:
The client stub packs (marshals) the procedure identifier and arguments into a call message.
3. Transmission:
The call message is sent over the network to the server via the RPC runtime system.
 2. Reply Messages

Purpose:
Reply messages are sent by the server to the client in response to call messages. They convey the result of the
remote procedure execution back to the client.

Key Components:

• Message Identification Field (Sequence Number):

o Function: Matches the reply to the corresponding call message.
o Details: Ensures that the client can correctly associate the reply with its original request.
• Message Type Field:
o Function: Identifies the message as a reply.
o Details: For example, this field might be set to 1 for reply messages.
• Reply Status Field:
o Function: Indicates whether the remote procedure executed successfully or if an error occurred.
o Details: A value of 0 might denote success, while non-zero values indicate different types of failures.
• Result Field (for Successful Replies):
o Function: Contains the return value or output data from the executed remote procedure.
o Details: The actual data resulting from the procedure's execution.
• Error Description Field (for Unsuccessful Replies):
o Function: Provides a description of the error that occurred during the remote procedure execution.
o Details: Helps the client understand the reason for the failure.

Process Flow:

1. Procedure Execution:
Upon receiving a call message, the server stub unpacks the message and invokes the specified remote
procedure with the provided arguments.
2. Marshaling the Reply:
After executing the procedure, the server stub packs the result (or error information) into a reply message.
3. Transmission:
The reply message is sent back to the client via the RPC runtime system.
4. Unmarshaling the Reply:
The client stub unpacks the reply message, retrieves the result or handles the error, and passes the information
back to the client application.

Marshaling and Unmarshaling

• Marshaling:
The process of encoding procedure identifiers and arguments into a call message before transmission.
• Unmarshaling:
The process of decoding the received call or reply message to extract procedure identifiers, arguments, results,
or error information.

Transparency Through Stubs

Stubs (client and server) play a pivotal role in ensuring that RPC mechanisms are transparent to the user:

• Abstraction of Network Communication:

Stubs hide the complexities of network communication, allowing programmers to invoke remote procedures
as if they were local function calls.
• Automatic Marshaling/Unmarshaling:
Stubs handle the encoding and decoding of messages, ensuring seamless data transmission without requiring
manual intervention.
• Error Handling:
Stubs manage communication errors, retries, and message matching, providing a reliable RPC experience.
 19) With a neat block diagram, explain how remote procedure call mechanism is implemented.

Implementation of Remote Procedure Call (RPC) Mechanism

The Remote Procedure Call (RPC) mechanism enables a program to cause a procedure to execute in another
address space (commonly on another physical machine) as if it were a local procedure call, abstracting the
complexities of network communication. This transparency is achieved through the use of stubs and an RPC
runtime on both the client and server sides.

Components of the RPC Mechanism

1. Client (Application)
o Role: Initiates the remote procedure call.
o Functionality: The client application invokes a procedure as if it were a local function. This invocation is
intercepted by the Client Stub.
2. Client Stub
o Role: Acts as a proxy for the remote procedure on the client side.
o Functions:
▪ Marshaling (Packing): Converts the procedure call and its arguments into a call message format suitable for
transmission over the network.
▪ Sending Call Message: Utilizes the RPC Runtime to send the marshaled call message to the server.
▪ Unmarshaling (Unpacking): Upon receiving the reply message, it unpacks the result and returns it to the
client application.
3. RPC Runtime (Client Side)
o Role: Manages the network communication for the client.
o Functions:
▪ Transmission: Handles the sending of call messages to the server and receiving of reply messages from the
server.
▪ Reliability Services: Manages retransmissions, acknowledgments, and error handling to ensure message
delivery.
4. Server Stub
o Role: Acts as a proxy for the remote procedure on the server side.
o Functions:
▪ Receiving Call Message: Receives the call message from the RPC Runtime.
▪ Unmarshaling (Unpacking): Converts the received call message back into procedure call and arguments.
▪ Executing Procedure: Invokes the actual procedure on the server application with the unpacked arguments.
▪ Marshaling Reply: Packs the result of the procedure execution into a reply message.
▪ Sending Reply Message: Sends the reply message back to the client via the RPC Runtime.
5. RPC Runtime (Server Side)
o Role: Manages the network communication for the server.
o Functions:
▪ Reception: Receives call messages from clients.
▪ Transmission: Sends reply messages back to the respective clients.
▪ Reliability Services: Ensures reliable message delivery through retransmissions, acknowledgments, and error
handling.
6. Server (Application)
o Role: Provides the remote services or procedures that clients invoke.
o Functionality: Executes the requested procedure upon invocation by the Server Stub and returns the result.

Workflow of an RPC Mechanism

1. Procedure Invocation:
o The Client Application calls a remote procedure as if it were a local function. This call is intercepted by the
Client Stub.
2. Marshaling the Call:
o The Client Stub marshals (packs) the procedure identifier and arguments into a Call Message.
3. Sending the Call Message:
o The Client Stub uses the RPC Runtime to send the Call Message over the network to the Server Stub.
4. Receiving and Unmarshaling the Call:
o The Server Runtime receives the Call Message and forwards it to the Server Stub.
o The Server Stub unmarshals (unpacks) the message to retrieve the procedure identifier and arguments.
5. Executing the Procedure:
o The Server Stub invokes the actual procedure in the Server Application with the provided arguments.
6. Marshaling the Reply:
o After execution, the Server Stub marshals the result into a Reply Message.
7. Sending the Reply Message:
o The Server Stub sends the Reply Message back to the Client Stub via the Server Runtime.
8. Receiving and Unmarshaling the Reply:
o The Client Runtime receives the Reply Message and forwards it to the Client Stub.
o The Client Stub unmarshals the message to retrieve the result.
9. Returning the Result:
o The Client Stub returns the result to the Client Application as if it were a local procedure call.

Key Points on RPC Transparency

• Abstraction of Network Communication:

o Stubs handle all the complexities of network communication, allowing the client and server applications to
interact through simple procedure calls without worrying about the underlying message-passing mechanisms.
• Marshaling and Unmarshaling:
o Automatic conversion of data structures and procedure calls into a format suitable for network transmission
(marshaling) and back into usable data structures upon receipt (unmarshaling).
• Seamless Integration:
o To the client and server applications, remote procedure calls appear indistinguishable from local procedure
calls, ensuring semantic transparency.
• Error Handling and Reliability:
o The RPC Runtime manages retransmissions, acknowledgments, and error detection, ensuring that message
delivery is reliable without burdening the client and server applications.

20) Expain two types of transparencies required for RPC. Is it possible to achieve complete semantic
transparency? Justify your answer

In Remote Procedure Call (RPC), transparency is a key design goal, where the objective is to make remote
procedures indistinguishable from local ones for the programmer. Two types of transparency are important:

1. Syntactic Transparency:

• This refers to making the remote procedure call look identical to a local procedure call in terms of syntax. The
programmer should be able to invoke a remote procedure in the same way they call a local one, without
requiring additional steps or different syntax.
• Example: A local call like sum(a, b) and a remote call should appear identical to the user.
• Achievability: Syntactic transparency is relatively easy to achieve. By using stub functions (client and server
stubs), RPC systems can ensure that the syntax for invoking remote procedures mimics local procedure
invocation.

2. Semantic Transparency:

• Semantic transparency means that a remote procedure call behaves identically to a local procedure call in all
aspects, including data handling, error handling, and performance.
• Challenges:
1. Address Space Separation: In an RPC, the client and server run in separate address spaces, unlike local
procedures. Hence, the remote procedure does not have direct access to the caller’s memory. Passing
references (pointers) becomes problematic, as they point to different address spaces.
2. Failure Handling: Remote procedure calls are susceptible to network failures, machine crashes, or
communication delays, which do not occur in local procedure calls. Handling such failures requires explicit
mechanisms in RPC.
3. Performance Issues: Remote procedure calls incur network latency, making them much slower (100 to 1000
times) than local calls. This delay needs to be handled by the application, especially in time-sensitive
processes.

Is Complete Semantic Transparency Possible?

No, complete semantic transparency is nearly impossible. This is primarily due to the fundamental
differences between local and remote procedure calls:

• Memory Sharing: The lack of shared memory makes passing references and complex data structures (like
linked lists or graphs) difficult without changing the semantics of the call.
• Failure Vulnerability: The possibility of failures (network issues, machine crashes) necessitates mechanisms
to detect and handle failures, which do not exist in local procedure calls.
• Performance Overhead: The significant difference in call execution times means that applications must
manage the delays, making perfect transparency unrealistic.