JNTU MCA DISTRIBUTED SYSTEMS Previous Question Paper (October/ November - 2020 - R15)

Designing a distributed system involves managing a collection of independent computers that appear to the user as a single coherent system. The primary challenges include:

1. Heterogeneity: Distributed systems often consist of diverse hardware, operating systems, networks, and programming languages. Middleware is required to provide a uniform abstraction layer to mask these differences.
2. Openness: Systems must be extensible and interoperable. This requires adherence to published standard interfaces and protocols, allowing new components to be integrated without disrupting existing services.
3. Security: With resources distributed across networks, security is complex. It involves ensuring confidentiality, integrity, and availability through authentication, authorization, and encryption, while protecting against threats like denial-of-service attacks.
4. Scalability: A system must remain efficient as the number of users or resources grows. Challenges include avoiding performance bottlenecks, preventing centralized data structures, and managing decentralized algorithms.
5. Failure Handling: Partial failures are inevitable. Designing for fault tolerance requires mechanisms such as redundancy, checkpointing, and recovery protocols to ensure the system continues to operate despite the failure of individual nodes or network links.
6. Concurrency: Multiple processes execute simultaneously and access shared resources. Managing this requires synchronization techniques like locks, semaphores, or distributed transactions to maintain data consistency.
7. Transparency: The system should hide its distributed nature from the user and application programmer. This includes access, location, migration, replication, and failure transparency.
8. Quality of Service (QoS): Maintaining performance guarantees such as latency, bandwidth, and reliability is difficult in unpredictable network environments where resource availability fluctuates.

Remote Procedure Call (RPC) is a communication protocol that allows a program to execute a procedure in another address space (commonly on another computer) as if it were a local procedure call. It hides the complexities of network communication by using stubs; the client stub marshals parameters into a message and sends them to the server, which unmarshals them, executes the procedure, and returns the result.

Remote Method Invocation (RMI) is a mechanism that allows an object residing in one Java Virtual Machine (JVM) to invoke methods on an object residing in another JVM. It is inherently object-oriented, supporting the passing of complex objects by value or by reference, and relies on the Java Remote Method Protocol (JRMP) to handle communication between objects.

The key differences between RPC and RMI are as follows:

While RPC is ideal for simple client-server interactions where performance and language interoperability are critical, RMI is preferred in Java-centric environments where distributed object-oriented design patterns and the ability to pass object references across the network are required.