4. Explain the features of distributed object model.

The distributed object model in a distributed system provides a framework for creating
applications where objects can communicate and interact with each other over a
network, even though they may reside on different machines. Here are some key
features of the distributed object model:

1. Transparency

• Location Transparency: Objects can interact without needing to know the

physical location of each other. The communication mechanism hides the
details of the network from the programmer.

• Access Transparency: Methods are invoked in the same way, whether the
object is local or remote, making remote interactions appear similar to local
ones.

2. Object-Oriented Paradigm

• Encapsulation: Objects encapsulate data and behavior, promoting modular

design and reusability.

• Inheritance and Polymorphism: Objects can inherit properties and behaviors

from other objects and can be treated as instances of their parent class,
facilitating code reuse and flexibility.

3. Remote Method Invocation (RMI)

• Method Invocation: Objects can invoke methods on remote objects as if they

were local. RMI handles the details of the network communication, such as
marshalling and unmarshalling of method parameters and return values.

• Stubs and Skeletons: These act as proxies to facilitate communication between

client and server objects. The stub resides on the client side and forwards calls
to the skeleton on the server side.

4. Naming and Directory Services

• RMI Registry: A naming service that allows clients to look up remote objects
by name. This service helps in locating and binding to remote objects.

• Directory Services: More advanced directory services can offer features like
object lookup based on attributes and provide a way to organize and manage
objects.

5. Concurrency
 • Multi-threading: Distributed object systems often support concurrent
processing, allowing multiple clients to interact with the same remote object
simultaneously.

• Synchronization: Mechanisms are provided to handle synchronization issues

that arise from concurrent accesses, ensuring data consistency and integrity.

6. Interoperability

• Protocol Support: Distributed object models support standard communication

protocols like TCP/IP, allowing objects on different platforms and written in
different languages to communicate.

• Cross-language Interaction: Some models, such as CORBA (Common Object

Request Broker Architecture), enable objects written in different programming
languages to interact seamlessly.

7. Security

• Authentication and Authorization: Mechanisms are in place to ensure that

only authorized clients can access remote objects.

• Encryption: Data transmitted over the network can be encrypted to protect

against eavesdropping and tampering.

• Sandboxing: Remote objects can be run in a controlled environment to prevent

them from performing harmful actions on the host system.

8. Scalability and Load Balancing

• Scalability: Distributed object systems can scale out by adding more servers to
handle increased load.

• Load Balancing: Requests to remote objects can be distributed across multiple

servers to balance the load and improve performance.

9. Fault Tolerance and Reliability

• Redundancy: Systems can replicate objects on multiple servers to provide

redundancy.

• Failover Mechanisms: If a server fails, the system can automatically switch to a

backup server to ensure continuous availability.

10. Lifecycle Management

• Creation and Destruction: The distributed object model provides mechanisms

for creating and destroying objects on remote servers.
 • Object Migration: Objects can be moved between servers to optimize resource
utilization and performance.

5. Explain the design issues of RMI.

Designing Remote Method Invocation (RMI) involves several critical issues that must
be addressed to ensure a robust, efficient, and secure system. Here are the primary
design issues associated with RMI:

1. Transparency

• Access Transparency: Ensuring that the distinction between local and remote
objects is minimized, so the client code does not need to be aware of whether
it is invoking a method on a local or a remote object.

• Location Transparency: The client should not need to know the physical
location of the remote object. This is typically handled by naming services like
the RMI registry.

2. Performance

• Latency: Remote method calls introduce network latency, which can affect
performance. Efficient serialization and deserialization, as well as minimizing the
number of remote calls, can help mitigate this.

• Throughput: The system should handle a large number of remote method

invocations efficiently. This may involve optimizing the communication protocol
and using connection pooling.

3. Scalability

• Load Balancing: The system should distribute the workload evenly across
multiple servers to prevent any single server from becoming a bottleneck.

• Replication: Replicating objects across multiple servers can improve availability

and fault tolerance, but it also introduces challenges in maintaining consistency.

4. Security

• Authentication: Ensuring that only authorized clients can invoke methods on

the remote objects.

• Authorization: Implementing fine-grained access control to determine what

each authenticated client is allowed to do.

• Confidentiality and Integrity: Protecting data from being intercepted and

tampered with during transmission. This often involves using encryption and
digital signatures.
5. Fault Tolerance

• Failure Detection: Mechanisms to detect failures in the remote server or

network.

• Recovery Mechanisms: Strategies for retrying failed requests or switching to

backup servers in case of failure.

• Idempotency: Designing methods to be idempotent, meaning repeated

execution of a method produces the same result, to handle retransmissions
gracefully.

6. Object Serialization

• Marshalling and Unmarshalling: Efficiently converting objects to a byte

stream for transmission over the network and reconstructing them at the
destination.

• Handling Complex Object Graphs: Dealing with objects that reference other
objects, including handling cyclic references and ensuring the entire object
graph is correctly serialized and deserialized.

7. Garbage Collection

• Distributed Garbage Collection: Managing the lifecycle of remote objects and

ensuring that they are properly cleaned up when no longer needed. This is more
complex than local garbage collection due to the involvement of multiple JVMs.

8. Naming and Directory Services

• Dynamic Binding: Allowing clients to discover and bind to remote objects at

runtime. This often involves using a naming service or directory service.

• Rebinding and Unbinding: Managing changes in the network topology or

object locations, and ensuring that clients can rebind to new objects as needed.

9. Concurrency Control

• Thread Management: Handling multiple concurrent remote method

invocations in a thread-safe manner.

• Synchronization: Ensuring that remote objects can handle concurrent access

from multiple clients without leading to race conditions or data inconsistencies.

10. Versioning and Compatibility

• Interface Evolution: Allowing remote interfaces to evolve over time without

breaking existing clients. This may involve supporting multiple versions of the
interface simultaneously.
 • Backward Compatibility: Ensuring that new versions of the remote object can
interact with older clients, and vice versa.

11. Protocol Design

• Transport Protocols: Choosing the appropriate transport protocol (e.g., TCP,

HTTP) for communication, considering factors like performance, reliability, and
compatibility with firewalls and proxies.

• Invocation Semantics: Defining the semantics of remote method invocations,

such as at-most-once, at-least-once, or exactly-once semantics.

12. Monitoring and Management

• Logging and Tracing: Implementing logging and tracing mechanisms to

monitor remote method invocations and diagnose issues.

• Performance Metrics: Collecting and analyzing performance metrics to

identify and address bottlenecks.

Addressing these design issues effectively ensures that an RMI system is robust,
scalable, secure, and efficient, providing a seamless experience for developers and
users alike.

6. Discuss about various Remote Procedure Calls.

Remote Procedure Call (RPC) is a powerful technique for constructing distributed,

client-server based applications. It is based on extending the conventional local
procedure calling so that the called procedure need not exist in the same address
space as the calling procedure. The two processes may be on the same system, or they
may be on different systems with a network connecting them.

When making a Remote Procedure Call:

Remote Procedure Calls (RPC) are a fundamental mechanism in distributed systems,
allowing programs to execute procedures on remote machines as if they were local.
Various types of RPC mechanisms have been developed, each addressing different
needs and challenges.

Synchronous RPC is the most straightforward form where the client sends a request
to the server and waits for a response, providing simplicity and ease of understanding
but suffering from blocking issues and potential performance bottlenecks, especially
in high-latency networks.

Asynchronous RPC improves upon this by allowing the client to continue execution
without waiting for a response, utilizing callbacks or futures to handle the server's
reply. This non-blocking approach enhances scalability and efficiency but adds
complexity to the client-side code and debugging process.

One-way RPC takes a "fire-and-forget" approach, where the client sends a request
without expecting any response. This method is efficient and reduces network traffic
but lacks confirmation of request processing, making it suitable only for certain use
cases where response validation is unnecessary.

Callback RPC combines the benefits of asynchronous communication with the

flexibility of server-side notifications. The server, upon completing a task, invokes a
specified procedure on the client. While this method is non-blocking and efficient, it
requires the client to handle incoming callbacks, adding to the overall complexity.

Batch-mode RPC addresses network efficiency by bundling multiple RPC calls into a
single request, reducing the number of round-trips needed. This batching can
significantly improve performance but introduces latency for individual requests and
necessitates sophisticated handling of request and response groups.

Broadcast and Multicast RPC involve sending a single request to multiple servers.
Broadcast RPC targets all servers, while multicast RPC targets a subset. These methods
enhance redundancy and load distribution but increase network traffic and require
mechanisms to handle multiple responses and potential conflicts.

Secure RPC incorporates encryption, authentication, and authorization to ensure

secure communication between clients and servers. While providing essential
protections against eavesdropping and tampering, these security measures can
introduce performance overhead and require comprehensive infrastructure
management.

Mobile RPC caters to environments with dynamic network conditions, supporting

clients that frequently change locations. This flexibility is crucial for mobile applications
but demands robust handling of network disconnections and varying latencies.
Cross-platform RPC enables interoperability between systems running different
operating systems or programming languages, often leveraging standard protocols
like HTTP/REST, SOAP, or gRPC. This approach facilitates communication across
diverse environments but can introduce overhead due to protocol translation and data
serialization differences.

Examples of RPC systems include Sun RPC, DCE/RPC, CORBA, Java RMI, gRPC, XML-
RPC, and JSON-RPC. Each has unique features tailored to specific scenarios, from
simple, language-agnostic communication (XML-RPC, JSON-RPC) to high-
performance, cross-language interactions (gRPC). The choice of RPC mechanism
depends on application requirements such as performance, scalability, security, and
platform compatibility.

Unit -2
5.A) Draw the structure of UDP datagram and explain about various structures
available in JAVA API for UDP transmission.

Structure of UDP Datagram

User Datagram Protocol (UDP) is a simple, connectionless protocol used for

transmitting data over a network. A UDP datagram consists of a header and data
section. The header is 8 bytes long, containing four fields: Source Port, Destination
Port, Length, and Checksum.

1. Source Port (16 bits): This is an optional field specifying the port number of
the sending application.

2. Destination Port (16 bits): This field specifies the port number of the receiving
application.

3. Length (16 bits): This field specifies the length of the UDP header and data in
bytes.

4. Checksum (16 bits): This field is used for error-checking of the header and
data.
The data section contains the actual payload to be delivered to the receiving
application. UDP is known for its simplicity and low overhead, but it does not provide
guaranteed delivery, order, or error correction.

UDP Structures in Java API

Java provides a comprehensive set of classes and interfaces for handling UDP
communication through the java.net package. The primary classes used for UDP
transmission are DatagramPacket and DatagramSocket.

1. DatagramPacket: This class represents a data packet to be sent or received

through a DatagramSocket. It includes methods for setting and getting the
data, address, and port.

2. DatagramSocket: This class represents a socket for sending and receiving

datagram packets. It provides methods for sending and receiving
DatagramPacket instances, binding to specific ports, and closing the socket.

Example structure for sending and receiving a UDP datagram in Java:

Example Code for Sending a UDP Datagram

Example Code for Receiving a UDP Datagram

6.A) Discuss in detail about Java API for TCP Stream

Java provides robust support for TCP (Transmission Control Protocol) stream
communication through its java.net package. TCP is a connection-oriented protocol
that ensures reliable, ordered, and error-checked delivery of data between applications
running on different hosts on a network. In Java, the primary classes used for TCP
communication are Socket, ServerSocket, and InetAddress.

The Socket class represents a client-side socket that can connect to a remote host
over TCP. When creating a Socket object, you specify the remote host's IP address and
port number. The Socket class provides methods for establishing connections, reading
from and writing to the socket, and closing the connection. Once connected, it uses
input and output streams to facilitate data transfer. Specifically, getInputStream() and
getOutputStream() methods return InputStream and OutputStream objects,
respectively, allowing you to read data from and write data to the connection.

The ServerSocket class represents a server-side socket that waits for requests to come
in over the network. It listens on a specific port and establishes a connection with a
client when a request is received. When a client connects, the accept() method of
ServerSocket returns a new Socket object representing the connection to the client.
The server can then interact with the client using the input and output streams
obtained from this Socket object.

The InetAddress class is used to represent an IP address. It provides methods to

resolve hostnames to IP addresses and vice versa, which is essential for establishing
TCP connections.

Code for TCP Server

 Code for TCP Client

1.With a neat sketch, Explain the implementation of Remote Method Invocation.

2.Explain communication between distributed objects, With a neat diagram.

3.What is the importance of distributed garbage collection? Explain the Distributed garbage
collector algorithm

4.Explain the features of distributed object model.

5.Explain the design issues of RMI.

6.Discuss about various Remote Procedure Calls.