Assignment 2

1) Explain the concept of inter-process communication (IPC) in distributed systems. Why is it crucial for distributed computing?

Inter-Process Communication (IPC) in Distributed Systems

Inter-process communication (IPC) refers to the mechanisms that allow different processes or programs running on separate machines (nodes) in a distributed system to communicate and exchange data with each other. It’s the lifeblood of distributed computing, enabling the various parts of a distributed application to work together cohesively.

Why is IPC crucial for distributed computing?

1. Collaboration and Coordination: Distributed systems often involve multiple processes working together to achieve a common goal. IPC allows these processes to coordinate their activities, share intermediate results, and synchronize their actions. Imagine a distributed e-commerce application: one process might handle inventory, another order processing, and yet another shipping. IPC allows them to communicate and ensure a smooth transaction flow.

2. Resource Sharing: Distributed systems often share resources like data, files, or hardware devices. IPC provides a way for processes to access and manage these shared resources in a controlled and coordinated manner, preventing conflicts and ensuring data consistency.

3. Modularity and Flexibility: Distributed systems are often designed as a collection of independent modules or services. IPC allows these modules to communicate with each other without needing to be tightly coupled. This promotes modularity, making it easier to develop, maintain, and update individual components.

4. Fault Tolerance and Resilience: If one process fails in a distributed system, other processes can continue to function. IPC mechanisms can help detect failures and enable other processes to take over or compensate for the failed process, ensuring the overall system remains operational.

5. Scalability and Performance: Distributing processing across multiple machines can significantly improve performance and scalability. IPC enables processes to communicate and exchange data efficiently, maximizing the benefits of distributed processing.

Common IPC Mechanisms:

Several IPC mechanisms are used in distributed systems, each with its own strengths and weaknesses:

• Remote Procedure Calls (RPC): Allows a process to call a procedure or function on a remote machine as if it were a local call. Simplifies distributed programming.
• Message Queues: Processes exchange messages asynchronously through a queue. Decouples processes and provides flexibility.
• Shared Memory: Processes share a common memory space for direct data exchange. Fast but requires careful synchronization.
• Sockets: A low-level mechanism for network communication, enabling processes to send and receive data over a network. Flexible but requires more coding effort.
• Web Services (e.g., REST, SOAP): Use standard protocols like HTTP to exchange data between applications over the web. Widely used for interoperability.

In essence: IPC is the glue that holds distributed systems together. Without effective IPC mechanisms, distributed computing would be impossible, as individual processes would operate in isolation, unable to collaborate or share information. The choice of IPC mechanism depends on the specific requirements of the distributed application, including performance, reliability, and complexity considerations.

2) What is the role of APIs in implementing internet protocols for communication in distributed systems? Provide examples.

APIs (Application Programming Interfaces) play a crucial role in implementing internet protocols for communication in distributed systems. They act as intermediaries, simplifying the complexities of underlying protocols and providing a standardized way for applications to interact with them. Think of them as translators or interfaces that abstract away the low-level details, making it easier for developers to build distributed applications.

Here’s a breakdown of their role and examples:

Role of APIs:

1. Abstraction: APIs hide the intricate details of internet protocols (like TCP/IP, HTTP, etc.) from developers. Developers don’t need to worry about packet formatting, network sockets, or other low-level details. The API handles these complexities behind the scenes.

2. Standardization: APIs provide a consistent and well-defined interface for interacting with protocols. This ensures that different applications, even if written in different languages or running on different platforms, can communicate seamlessly.

3. Simplified Development: APIs make it much easier and faster to develop distributed applications. Developers can focus on the application logic rather than the complexities of network communication.

4. Code Reusability: APIs often provide pre-built functions and libraries that developers can reuse, saving time and effort.

5. Interoperability: APIs enable different systems and applications to communicate with each other, even if they are built using different technologies.

Examples:

1. Socket API: This is a low-level API that provides direct access to network sockets. It allows applications to create connections, send and receive data over the network using protocols like TCP and UDP. While powerful, it requires developers to handle many low-level details. It’s the foundation upon which many higher-level APIs are built.

2. HTTP Libraries (e.g., requests in Python, http in Node.js): These libraries provide a higher-level interface for working with the HTTP protocol. They simplify tasks like making HTTP requests (GET, POST, etc.), handling responses, and managing headers. Developers don’t need to worry about the underlying socket communication. These are essential for building web applications that interact with distributed services.

3. RESTful APIs: REST (Representational State Transfer) is an architectural style for building web services. RESTful APIs use HTTP methods (GET, POST, PUT, DELETE) to interact with resources. They often use formats like JSON or XML for data exchange. These APIs are widely used for building distributed systems because of their simplicity and scalability. Many cloud services (like AWS, Google Cloud) provide RESTful APIs for accessing their services.

4. RPC Frameworks (e.g., gRPC, Apache Thrift): RPC (Remote Procedure Call) frameworks provide APIs for making remote procedure calls. They abstract away the details of network communication, making it seem like you are calling a function on the same machine, even though it might be running on a remote server. These are useful for building distributed systems where inter-service communication is frequent.

5. Message Queue APIs (e.g., libraries for RabbitMQ, Kafka): Message queues are used for asynchronous communication in distributed systems. APIs for message queues provide functions for sending and receiving messages, managing queues, and handling message delivery. They abstract the complexities of the underlying message queueing system.

In short: APIs provide a user-friendly and standardized way to interact with internet protocols, simplifying the development of distributed systems and promoting interoperability between different applications. They are essential building blocks for modern distributed applications and services.

3) What is external data representation (e.g., XDR)? Why is it important in achieving interoperability in distributed systems?

External Data Representation (XDR)

In distributed systems, different machines may have varying architectures, operating systems, and programming languages. This heterogeneity can create challenges when these systems need to communicate and exchange data. This is where External Data Representation (XDR) comes in.

XDR is a standard format for representing data structures and primitive values in a way that is independent of the specific machine or system. It provides a common language for describing data, allowing systems with different internal representations to understand and interpret the data being exchanged.

Why is XDR important for interoperability?

1. Platform Independence: XDR ensures that data can be exchanged between systems with different architectures (e.g., big-endian vs. little-endian), operating systems, and programming languages. It acts as a bridge, allowing these diverse systems to understand each other’s data.

2. Data Consistency: XDR defines a standard way of representing data types (integers, floating-point numbers, strings, etc.), ensuring that data is interpreted consistently across different systems. This prevents errors and misinterpretations that could arise from differing internal data representations.

3. Simplified Communication: XDR simplifies the process of data exchange by providing a common format that all participating systems can understand. This eliminates the need for complex data conversions or translations, making communication more efficient and reliable.

4. Improved Interoperability: By providing a standardized way of representing data, XDR significantly improves interoperability between different distributed systems. This allows systems to seamlessly exchange data and collaborate, even if they are built using different technologies.

How does XDR work?

XDR defines a set of rules for encoding data into a standard format. This encoded data can then be transmitted over the network to another system. The receiving system can then decode the XDR data back into its own internal representation.

Example:

Imagine two systems, one using a big-endian architecture and the other using a little-endian architecture, need to exchange an integer value. Without XDR, the big-endian system would store the most significant byte of the integer first, while the little-endian system would store it last. This would lead to misinterpretation of the data.

With XDR, both systems would encode the integer into the XDR format, which specifies a standard byte order. This ensures that both systems interpret the integer correctly, regardless of their internal architectures.

In summary:

XDR is a crucial technology for achieving interoperability in distributed systems. By providing a standard way of representing data, it enables diverse systems to communicate and exchange information seamlessly, facilitating collaboration and data sharing in complex distributed environments.

4) What is network virtualization, and how do overlay networks contribute to building virtual networks?

Network Virtualization

Network virtualization is the technology that allows you to create multiple virtual networks on top of a single physical network infrastructure. It’s like having several independent networks running on the same set of hardware, each with its own configurations, security policies, and traffic isolation.

How Overlay Networks Contribute

Overlay networks are a key component of network virtualization. They are virtual networks that are built on top of an existing physical network (often called the “underlay” network). Think of it like laying a new road on top of an existing highway system.

Here’s how they contribute:

1. Abstraction: Overlay networks abstract the underlying physical network infrastructure. This means that the virtual networks are independent of the physical topology. You can create virtual networks that span multiple physical switches and routers without needing to reconfigure the physical network.

2. Isolation: Overlay networks provide isolation between different virtual networks. This means that traffic on one virtual network is isolated from traffic on other virtual networks, even if they share the same physical infrastructure. This is important for security and privacy.

3. Flexibility: Overlay networks provide flexibility in how you design and manage your networks. You can create virtual networks with different topologies, addressing schemes, and security policies, all on the same physical infrastructure.

4. Scalability: Overlay networks can be easily scaled to accommodate changing needs. You can add or remove virtual networks without needing to make changes to the physical network.

How Overlay Networks Work

Overlay networks work by encapsulating network traffic within the physical network’s packets. This means that the data packets from the virtual network are wrapped in headers that identify the virtual network and the destination within that virtual network. The physical network then treats these encapsulated packets as regular data packets, forwarding them to the correct destination.

Examples of Overlay Network Technologies

• VXLAN (Virtual Extensible LAN): A popular technology for creating overlay networks in data centers.
• NVGRE (Network Virtualization using Generic Routing Encapsulation): Another technology for network virtualization, often used in Microsoft environments.
• GRE (Generic Routing Encapsulation): A tunneling protocol that can be used to create overlay networks.

Benefits of Network Virtualization with Overlay Networks

• Improved Resource Utilization: You can make better use of your physical network infrastructure by running multiple virtual networks on it.
• Increased Agility: You can quickly create and modify virtual networks to meet changing needs.
• Enhanced Security: You can isolate traffic between different virtual networks to improve security.
• Simplified Management: You can manage virtual networks independently, making it easier to configure and troubleshoot them.

In summary, network virtualization, with the help of overlay networks, provides a powerful way to create and manage virtual networks on top of existing physical infrastructure. This offers numerous benefits in terms of resource utilization, agility, security, and management.

5) What are the key features of MPI, and how does it facilitate communication in distributed computing environments?

The Message Passing Interface (MPI) is a standardized library for writing parallel programs that can run on distributed memory systems, like clusters of computers. It’s a crucial tool for high-performance computing and enables efficient communication in distributed computing environments. Here are some of its key features:

1. Process Management:

• Process Groups: MPI allows you to organize processes into groups, facilitating collective operations and managing communication scopes.
• Ranks: Each process within a group is assigned a unique rank (an integer identifier), enabling processes to be distinguished and targeted for communication.

2. Point-to-Point Communication:

• Send and Receive: MPI provides functions for sending messages from one process to another specific process.
• Blocking and Non-blocking Operations: MPI supports both blocking (where the sending process waits until the message is sent) and non-blocking (where the sending process can continue with other tasks while the message is sent in the background) communication modes.
• Message Tags: Messages can be tagged with identifiers, allowing the receiver to selectively receive messages based on their content or purpose.

3. Collective Communication:

• Broadcast: Distributes a message from one process to all other processes in a group.
• Gather: Collects data from all processes in a group into a single process.
• Scatter: Distributes data from one process to all other processes in a group.
• Reduce: Performs a reduction operation (e.g., sum, product, max, min) on data from all processes in a group and returns the result to one or all processes.
• All-to-all: Each process sends data to and receives data from all other processes in a group.

4. Data Types:

• Predefined Data Types: MPI supports communication of various predefined data types (integers, floating-point numbers, characters, etc.).
• Derived Data Types: MPI allows you to create custom data types for more complex data structures, enabling efficient communication of non-contiguous data.

5. Communicators:

• Communication Context: Communicators define the scope of communication, specifying which processes can participate in communication operations.
• Intra-communicators: Used for communication within a single group of processes.
• Inter-communicators: Used for communication between two distinct groups of processes.

How MPI Facilitates Communication:

• Explicit Message Passing: MPI relies on explicit message passing, where processes explicitly send and receive messages to exchange data. This provides fine-grained control over communication.
• Standardized Interface: MPI provides a standardized API that can be used across different platforms and programming languages (C, C++, Fortran). This ensures portability of parallel code.
• Optimized for Distributed Memory: MPI is designed to work efficiently on distributed memory systems, where each process has its own local memory. It handles the complexities of data transfer and synchronization between processes.
• Scalability: MPI enables parallel programs to scale to a large number of processors, making it suitable for solving complex scientific and engineering problems.

In summary:

MPI is a powerful tool for writing parallel programs that can run on distributed memory systems. Its key features provide a flexible and efficient way for processes to communicate and collaborate, enabling the development of scalable and high-performance distributed applications.

6) Compare and contrast remote procedure calls (RPC) with remote method invocation (RMI). How does Java RMI enable distributed object communication?

This is for informational purposes only. For medical advice or diagnosis, consult a professional.

RPC vs. RMI: A Comparative Analysis

Both Remote Procedure Calls (RPC) and Remote Method Invocation (RMI) are mechanisms for enabling communication between processes in distributed systems. However, they differ in their approach and features.

RPC (Remote Procedure Calls)

• Procedural Focus: RPC is centered around calling procedures or functions on a remote machine. It’s like making a function call in your local code, but the actual execution happens on a different machine.
• Language Neutrality: RPC is designed to be language-agnostic. Systems written in different languages can communicate with each other using RPC.
• Data Exchange: RPC typically focuses on exchanging data in a structured format, often using Interface Definition Languages (IDLs) to define the data structures.
• Examples: Sun RPC, DCE RPC

RMI (Remote Method Invocation)

• Object-Oriented Focus: RMI extends the concept of RPC to support object-oriented programming. It allows you to invoke methods on remote objects, treating them as if they were local objects.
• Java-Specific: RMI is primarily associated with Java and is tightly integrated with the Java platform.
• Object Serialization: RMI uses object serialization to marshal and unmarshal objects for transmission between systems. This allows complex objects with methods and state to be passed around.
• Examples: Java RMI, CORBA

Comparison Table

Java RMI: Enabling Distributed Object Communication

Java RMI provides a mechanism for Java objects running on different Java Virtual Machines (JVMs) to communicate with each other. It leverages Java’s object serialization and reflection capabilities to achieve this.

Key Aspects of Java RMI:

1. Remote Interfaces: Define the methods that can be invoked remotely. These interfaces must extend the java.rmi.Remote interface.

2. Remote Object Implementation: Implement the remote interface and provide the actual implementation for the remote methods.

3. Stub and Skeleton:

   • Stub: A client-side proxy that acts as a stand-in for the remote object. It handles the communication with the remote server.
   • Skeleton: A server-side proxy that receives the method call from the stub, dispatches it to the actual remote object implementation, and sends the result back to the client.

4. Registry: A naming service that allows clients to look up remote objects by name.

How Java RMI Works:

1. The client obtains a reference to the remote object (stub) from the registry.
2. The client invokes a method on the stub as if it were a local object.
3. The stub marshals the method call and its arguments and sends them to the server.
4. The skeleton on the server receives the call, unmarshals the arguments, and invokes the corresponding method on the remote object implementation.
5. The result is marshalled by the skeleton and sent back to the client.
6. The stub unmarshals the result and returns it to the client.

Benefits of Java RMI:

• Seamless Remote Object Interaction: Java RMI makes it easy to work with remote objects as if they were local, simplifying distributed application development.
• Integration with Java: RMI is tightly integrated with the Java platform, making it a natural choice for Java-based distributed systems.
• Object Serialization: RMI’s use of object serialization allows complex objects to be exchanged between systems, preserving their state and behavior.

In summary:

Java RMI provides a powerful and convenient way for Java objects to communicate in a distributed environment. Its object-oriented approach and seamless integration with the Java platform make it a popular choice for building Java-based distributed applications.

7) ​Explain the publish-subscribe communication model. How does it differ from traditional request-reply protocols?

The publish-subscribe (pub-sub) communication model is a messaging paradigm where senders (publishers) do not directly address their messages to specific receivers (subscribers). Instead, messages are categorized into topics or subjects, and subscribers express interest in receiving messages related to specific topics. The system then delivers messages matching those topics to the appropriate subscribers. It’s like subscribing to a magazine – you don’t tell the publisher how to deliver it, just what you want to read.

Key Components:

• Publishers: Entities that create and send messages. They publish messages to specific topics.
• Subscribers: Entities that register their interest in receiving messages related to one or more topics.
• Topics/Channels: Categories or subjects that organize messages. Publishers publish to topics, and subscribers subscribe to topics.
• Message Broker/Router: A central component (though it can be distributed) that manages topics, filters messages, and delivers them to the appropriate subscribers.

How it Works:

1. Subscription: Subscribers register their interest in specific topics with the message broker.
2. Publication: Publishers send messages to the message broker, specifying the topic.
3. Routing: The message broker matches the message’s topic with the subscriptions and delivers the message to all interested subscribers.

Differences from Request-Reply Protocols:

Advantages of Publish-Subscribe:

• Decoupling: Publishers and subscribers are independent of each other, improving system flexibility and maintainability.
• Scalability: The system can easily handle a large number of publishers and subscribers.
• Flexibility: New subscribers can be added without affecting publishers, and vice versa.
• Real-time Communication: Ideal for applications that require real-time updates and notifications.

Disadvantages of Publish-Subscribe:

• Complexity: Implementing a robust pub-sub system can be more complex than a simple request-reply system.
• Message Delivery Guarantees: Ensuring reliable message delivery can be challenging, especially in distributed environments.
• Debugging: Tracing messages and identifying issues can be more difficult due to the decoupled nature of the system.

In Summary:

The publish-subscribe model offers a powerful and flexible approach to communication in distributed systems, especially for applications that require real-time updates, scalability, and decoupling. It contrasts sharply with request-reply models by enabling asynchronous, one-to-many communication, leading to different trade-offs in terms of complexity, fault tolerance, and use cases.

8) How do Enterprise Java Beans (EJB) facilitate component-based development in distributed systems? Highlight key differences between distributed objects and components.

This is for informational purposes only. For medical advice or diagnosis, consult a professional.

EJBs: Enabling Component-Based Development in Distributed Systems

Enterprise Java Beans (EJBs) are a crucial technology for building component-based distributed systems in Java. They provide a standardized architecture and runtime environment for developing, deploying, and managing server-side components that encapsulate business logic.

How EJBs Facilitate Component-Based Development:

1. Component Abstraction: EJBs allow you to encapsulate business logic into reusable components (beans). This promotes modularity and makes it easier to develop, maintain, and update complex applications.

2. Container-Managed Services: The EJB container provides a set of services to EJBs, such as transaction management, security, concurrency control, and resource pooling. This frees developers from having to implement these services themselves, allowing them to focus on the business logic.

3. Simplified Development: EJBs simplify distributed application development by providing a standard framework for handling common tasks like remote communication, object lifecycle management, and persistence.

4. Deployment and Management: EJBs are deployed and managed within an EJB container, which provides a runtime environment for the beans. The container handles tasks like bean instantiation, lifecycle management, and resource allocation.

5. Scalability and Performance: EJBs are designed to be scalable and performant. The container can manage a pool of beans, allowing the system to handle a large number of requests concurrently.

Key Differences Between Distributed Objects and Components:

In Summary:

EJBs provide a powerful framework for building component-based distributed systems in Java. They promote modularity, simplify development, and provide a runtime environment with essential services. By encapsulating business logic into reusable components, EJBs enable developers to build scalable, maintainable, and robust enterprise applications.

9) Describe the architecture of Java RMI. How does it ensure transparency and efficiency in remote communication?

Let’s break down the architecture of Java Remote Method Invocation (RMI) and how it achieves transparency and efficiency in remote communication.

Java RMI Architecture:

RMI’s architecture revolves around several key components working together:

1. Remote Interface: This interface defines the methods that can be called remotely. It must extend java.rmi.Remote. It acts as a contract between the client and the server.

2. Remote Object Implementation: This class implements the remote interface and contains the actual implementation of the remote methods. It resides on the server.

3. Stub (Client-side proxy): The stub acts as a proxy for the remote object on the client side. It implements the same remote interface as the server object. When the client calls a method on the stub, it appears as if the client is calling a local method.

4. Skeleton (Server-side proxy): The skeleton resides on the server and acts as a proxy for the remote object. It receives the method call from the stub, unmarshals the arguments, and then invokes the corresponding method on the actual remote object implementation.

5. RMI Registry: The registry is a naming service that allows clients to look up remote objects by name. The server registers its remote objects with the registry, and the client retrieves the stub for the remote object from the registry.

6. RMI Runtime Environment: This environment manages the communication between the client and the server, handling tasks like marshaling/unmarshaling arguments and return values, and managing connections.

How RMI Ensures Transparency:

RMI achieves transparency by making remote method calls appear as much like local method calls as possible. This is done through the stub and skeleton:

• Location Transparency: The client doesn’t need to know the location of the remote object. It interacts with the stub as if it were a local object. The RMI runtime handles the details of locating the server and communicating with it.
• Interface Transparency: The stub implements the same interface as the remote object. This means that the client code doesn’t need to be aware that it’s interacting with a remote object. The method calls look the same whether the object is local or remote.

How RMI Ensures Efficiency:

RMI employs several mechanisms to improve efficiency:

• Serialization: RMI uses Java’s serialization mechanism to convert objects into a byte stream for transmission over the network. This allows complex objects to be passed between the client and the server.
• Stub and Skeleton: The stub and skeleton handle the marshaling and unmarshaling of arguments and return values, optimizing the data transfer process.
• TCP/IP: RMI typically uses TCP/IP for communication, which provides reliable, ordered delivery of data.
• Registry Caching: Clients can cache stubs retrieved from the registry to avoid repeated lookups.

Communication Flow:

1. The server creates the remote object and registers it with the RMI registry.
2. The client looks up the remote object in the registry and obtains the stub.
3. The client calls a method on the stub.
4. The stub marshals the method call and its arguments and sends them to the skeleton on the server.
5. The skeleton unmarshals the arguments and invokes the method on the remote object.
6. The remote object performs the method and returns the result to the skeleton.
7. The skeleton marshals the result and sends it back to the stub.
8. The stub unmarshals the result and returns it to the client.

In Summary:

Java RMI provides a powerful and convenient way to build distributed applications in Java. Its architecture, with its use of stubs, skeletons, and the registry, ensures transparency and efficiency in remote communication, making it easier for developers to create and manage distributed Java objects.

10) Write a Java RMI application where the server provides a method to calculate the factorial of a given number. The client should remotely invoke this method and display the result.

// Server Interface (FactorialInterface.java)
import java.rmi.*;
 
public interface FactorialInterface extends Remote {
    long calculateFactorial(int n) throws RemoteException;
}
 
// Server Implementation (FactorialServer.java)
import java.rmi.server.UnicastRemoteObject;
import java.rmi.registry.Registry;
import java.rmi.registry.LocateRegistry;
 
public class FactorialServer extends UnicastRemoteObject implements FactorialInterface {
 
    public FactorialServer() throws RemoteException {
        super();
    }
 
    public long calculateFactorial(int n) throws RemoteException {
        if (n < 0) {
            throw new IllegalArgumentException("Factorial is not defined for negative numbers.");
        }
        if (n == 0) {
            return 1;
        }
        long result = 1;
        for (int i = 1; i <= n; i++) {
            result *= i;
        }
        return result;
    }
 
    public static void main(String[] args) {
        try {
            FactorialServer server = new FactorialServer();
            String serverName = "FactorialService"; // Give a name to the RMI service
 
            // Create and export the registry if it doesn't exist
            try {
                 LocateRegistry.createRegistry(Registry.REGISTRY_PORT); // Default RMI registry port
            } catch (Exception e) {
                 // Registry probably already exists, do nothing
            }
 
            Registry registry = LocateRegistry.getRegistry(); // Get reference to the registry
            registry.bind(serverName, server); // Bind the server object to the name
 
            System.out.println("Factorial server is running...");
 
        } catch (Exception e) {
            System.err.println("Server exception: " + e.toString());
            e.printStackTrace();
        }
    }
}
 
 
// Client (FactorialClient.java)
import java.rmi.registry.Registry;
import java.rmi.registry.LocateRegistry;
 
public class FactorialClient {
 
    public static void main(String[] args) {
        try {
            String serverName = "FactorialService";
            Registry registry = LocateRegistry.getRegistry(); // Get reference to the registry (default port)
 
            FactorialInterface stub = (FactorialInterface) registry.lookup(serverName); // Look up the remote object
 
            int number = 5; // Example number, you can change this
            long factorial = stub.calculateFactorial(number);
            System.out.println("Factorial of " + number + " is: " + factorial);
 
            number = -2;
            factorial = stub.calculateFactorial(number); // Example number, you can change this
            System.out.println("Factorial of " + number + " is: " + factorial); // This will throw an exception
 
        } catch (Exception e) {
            System.err.println("Client exception: " + e.toString());
            e.printStackTrace();
        }
    }
}

Steps to Run:

1. Compile: Compile all three Java files (interface, server, and client). javac *.java
2. Start RMI Registry: Open a terminal and start the RMI registry. rmiregistry (If the registry is already running, you can skip this step. The server code now tries to start it if it’s not running).
3. Start Server: Open another terminal and run the server. java FactorialServer
4. Start Client: Open a third terminal and run the client. java FactorialClient

Explanation:

• Interface: The FactorialInterface defines the contract for the remote service.
• Server: FactorialServer implements the interface and provides the factorial calculation logic. It registers itself with the RMI registry.
• Client: FactorialClient looks up the remote object in the registry and invokes the calculateFactorial method.

Key Improvements:

• Error Handling: Includes a check for negative input in the server and handles potential exceptions in both client and server.
• Registry Handling: The server now attempts to create the registry if it’s not already running. This makes it easier to start the server.
• Clearer Comments: Added more comments to explain the code.
• Service Name: Uses a named service (“FactorialService”) which is more robust.

This improved example provides a more complete and robust RMI application. Remember to have the rmiregistry running before starting the server.