Interprocess Communication and Internet Protocols

In this section, we cover the general characteristics of interprocess communication (IPC) and
explore Internet protocols, particularly focusing on how programmers can utilize them through
User Datagram Protocol (UDP) messages and Transmission Control Protocol (TCP) streams.

4.2.1 Characteristics of Interprocess Communication

Interprocess communication is facilitated through two primary operations: send and receive.
Here’s an overview of how these operations work and their implications in a distributed system:

 Message Passing: A process sends a message (a sequence of bytes) to a destination

process, which receives it. This communication involves data transfer and may also require
synchronization between the processes.

 Synchronous vs. Asynchronous Communication:

o Synchronous Communication:

 Both sending and receiving processes synchronize during message transfer.

 Blocking Operations:

 A sending process is blocked until the corresponding receive is

issued.

 A receiving process is blocked until a message is received.

o Asynchronous Communication:

 Sending is non-blocking; the sender can proceed once the message is

copied to a local buffer.

 The receiving process may operate in blocking or non-blocking modes:

 Blocking Receive: The receiving process waits until a message is

available.

 Non-blocking Receive: The receiving process continues execution

and must later check (polling) or be notified (interrupt) when a
message is available.

 Threading Considerations: In environments like Java, where multiple threads exist within a
single process, blocking receives can be advantageous, allowing other threads to remain
active while waiting for a message.

Message Destinations

Messages in Internet protocols are directed to specific (Internet address, local port) pairs:

 Local Ports: Each port is associated with exactly one receiver (multicast ports are an
exception) and can have multiple senders. Processes can use multiple ports for receiving
messages.

 Location Transparency: To enable services to be relocated while maintaining their

accessibility:
 o Client programs refer to services by name.

o A name server or binder translates these names into server locations during
runtime.

Reliability and Ordering

 Reliable Communication: A point-to-point message service is considered reliable if it

guarantees message delivery despite a reasonable number of packet losses. In contrast, an
unreliable service does not ensure delivery even with a single lost packet.

 Integrity: Messages must arrive uncorrupted and without duplication.

 Ordering: Some applications require messages to be delivered in the order they were sent.
Delivery out of order is treated as a failure in these scenarios.

4.2.2 Sockets

Both UDP and TCP use the socket abstraction, providing endpoints for communication between
processes. Here’s how sockets function:

 Socket Communication: Messages are transmitted between a socket in one process and a
socket in another process. For a socket to receive messages, it must be bound to a local
port and an Internet address.

 Socket Properties:

o Each computer can have a significant number of port numbers (up to

2162^{16}216), and processes can use multiple ports for receiving messages.

o A socket is associated with either UDP or TCP.

4.2.3 Java API for UDP

The Java API provides interfaces for UDP communication, allowing developers to send and receive
messages using UDP sockets. Some important classes and methods include:

 DatagramSocket: Represents a socket for sending and receiving datagram packets.

 DatagramPacket: Represents a packet of data to be sent or received.

Example of creating a UDP socket in Java:

java

Copy code

DatagramSocket socket = new DatagramSocket();

4.2.4 Java API for TCP

For TCP communication, Java provides similar APIs for stream-oriented communication:

 ServerSocket: Used by servers to listen for incoming TCP connections.

 Socket: Represents a client socket for establishing connections to servers.

Example of creating a TCP socket in Java:

Socket socket = new Socket("hostname", portNumber);

Java API for Internet Addresses

Java provides the InetAddress class for representing Internet addresses. This class encapsulates the
details of address representation, allowing users to refer to computers by their DNS hostnames.
For example, to get an Internet address for a hostname:

InetAddress aComputer = InetAddress.getByName("bruno.dcs.qmul.ac.uk");

This method can throw an UnknownHostException if the hostname cannot be resolved.

Conclusion

Understanding interprocess communication and the associated Internet protocols, particularly

through the lens of the Java APIs for UDP and TCP, allows programmers to effectively implement
distributed systems. By utilizing sockets for message passing and ensuring reliability, integrity, and
proper ordering of messages, developers can create robust applications that communicate over
networks.
1. Overview of Request-Reply Communication

 Synchronous Communication: In typical client-server interactions, communication is

synchronous, meaning the client waits (blocks) until a reply is received from the server. This
mechanism ensures reliability since the reply acts as an acknowledgment of the client's
request.

 Asynchronous Communication: This is an alternative where clients can retrieve replies later,
useful when immediate responses are not critical.

2. Communication Primitives

The request-reply protocol is illustrated with three core communication primitives, which are
fundamental operations for interaction between clients and servers:

 doOperation: This method is invoked by clients to perform remote operations. It takes

arguments that specify the server, operation to execute, and any additional necessary data.
The result is a byte array containing the server's reply.

 getRequest: Used by the server to acquire incoming client requests.

 sendReply: This sends the reply message from the server back to the client.

Example Method Signatures:

java

Copy code

public byte[] doOperation(RemoteRef s, int operationId, byte[] arguments);

public byte[] getRequest();

public void sendReply(byte[] reply, InetAddress clientHost, int clientPort);

3. Message Structure

Each message in the request-reply communication consists of several fields:

 messageType: Indicates whether the message is a request or a reply (0 = Request, 1 = Reply).

 requestId: A unique identifier for each request, which helps in matching replies to the
corresponding requests.

 remoteReference: A reference to the remote server.

 operationId: Identifier for the operation being invoked.

 arguments: Data passed to or returned from the operation.

4. Message Identifiers

 Each message needs a unique identifier to facilitate reliable communication. This consists of
a requestId (generated from an increasing integer sequence) and a sender identifier (e.g.,
port and Internet address).

5. Failure Model
The request-reply protocol implemented over UDP faces various challenges:

 Omission Failures: Messages may not be delivered.

 Out-of-order Delivery: Messages may arrive out of the intended sequence.

 Process Failures: Servers may crash without warning.

6. Timeouts and Retransmissions

To handle situations where replies may not be received:

 Timeouts: The doOperation method employs timeouts to wait for a reply. After a timeout, it
may either:

o Return immediately indicating failure (not common).

o Retransmit the request until a reply is received or a failure is confirmed.

7. Handling Duplicate Requests

If a request is retransmitted, the server may receive it multiple times. To prevent executing the same
request more than once:

 The server filters duplicate requests based on their requestId.

8. Idempotent Operations

Some operations are idempotent, meaning they can be performed multiple times without changing
the result beyond the initial application. For instance:

 Adding an element to a set is idempotent.

 Appending an item to a sequence is not idempotent.

9. History for Retransmissions

To manage replies efficiently:

 History: Servers may maintain a history of sent replies to avoid re-executing operations
unnecessarily. Entries in the history include request identifiers and the corresponding reply
messages.

10. Protocol Variants

Three types of request protocols provide different behaviors during communication failures:

 Request (R): A single request is sent; no reply or confirmation needed.

 Request-Reply (RR): The server’s reply is considered an acknowledgment of the request.

 Request-Reply-Acknowledge (RRA): Involves an additional acknowledgment message to

confirm receipt of replies.

11. Implementation Over TCP vs. UDP

 TCP: Provides reliable delivery, so retransmission and duplicate filtering mechanisms are
unnecessary. This simplifies protocol implementation and allows for larger message sizes
without worrying about datagram limits.
  UDP: While more lightweight, it requires additional mechanisms for reliability, such as
handling retransmissions and managing message histories.

12. HTTP as a Request-Reply Protocol

HTTP (Hypertext Transfer Protocol) exemplifies a request-reply protocol:

 Clients send requests to web servers and receive replies. Requests can include various
methods (GET, POST, PUT, DELETE), each serving specific purposes in data retrieval and
manipulation.

 HTTP supports content negotiation, allowing clients to specify acceptable data formats, and
uses persistent connections to optimize performance by keeping connections open for
multiple exchanges.

Overview of RPC

 Definition: RPC enables calling procedures on remote machines as if they were local,
achieving distribution transparency. This was first introduced by Birrell and Nelson in 1984.

 Goals: The main goal is to simplify programming for distributed systems, making it similar to
conventional programming.

Design Issues

1. Programming with Interfaces:

o Interfaces control interactions between modules, defining accessible procedures and

variables.
 o In distributed systems, service interfaces specify procedures available on servers,
promoting abstraction and hiding implementation details.

2. Benefits of Interfaces:

o Programmers focus on the service interface without needing implementation

knowledge.

o Supports heterogeneous systems, allowing different programming languages to

communicate.

o Facilitates software evolution; changes in implementation do not affect users as long

as the interface remains the same.

3. Interface Definition Languages (IDLs):

o IDLs define interfaces for remote invocations, allowing communication between

different programming languages.

o Example: CORBA IDL specifies methods and parameter types (e.g., input/output).

RPC Call Semantics

RPC systems can implement different call semantics, affecting reliability:

 Maybe Semantics: The procedure may execute once or not at all, leading to uncertainty
about execution due to potential message loss.

 At-least-once Semantics: Guarantees that the invoker receives a result or an exception; it can
cause procedures to execute multiple times, which is problematic for non-idempotent
operations.

 At-most-once Semantics: Ensures the procedure is executed exactly once or not at all,
preventing duplicate executions.

Transparency in RPC

 RPC aims to make remote calls as similar as possible to local calls, hiding complexities such as
marshalling and message-passing.

 It achieves location and access transparency but is more susceptible to failures compared to
local calls.

 The latency of RPCs is significantly greater than local calls, necessitating careful design to
manage remote interactions effectively.

Conclusion

The consensus in RPC design is that while remote calls should be syntactically similar to local calls,
differences should be clearly expressed in their interfaces. Designers must consider how call
semantics influence system reliability and manage potential failures effectively.

This summary captures the essence of the concepts discussed in your excerpt. If you need a more in-
depth analysis of specific sections or further information, feel free to ask!
Key Components of RPC

1. Client Process: This is the program that initiates the RPC by invoking a procedure on the
server.

o Client Stub Procedure: Acts as a local proxy for the service procedure on the server.
It marshals (packages) the procedure identifier and arguments into a request
message before sending it to the server.

2. Communication Module: This handles the transmission of messages between the client and
the server, ensuring the request message is sent and the reply message is received.

3. Server Process: This runs on the server and is responsible for executing the requested
service procedures.

o Dispatcher: Receives incoming requests and determines which server stub

procedure to invoke based on the procedure identifier in the request message.

o Server Stub Procedure: Unmarshals (extracts) the arguments from the request
message, invokes the corresponding service procedure, and marshals the return
values into a reply message.

o Service Procedure: Implements the actual logic of the service requested by the
client.

RPC Workflow

1. Client Invocation: The client invokes a procedure as if it were a local call.

2. Marshalling: The client stub marshals the procedure identifier and arguments into a request
message.

3. Sending Request: The communication module sends the request message to the server.

4. Server Handling:

o The dispatcher receives the request and determines the correct server stub to call.

o The server stub unmarshals the request to extract the procedure identifier and
arguments.

o The corresponding service procedure is called to perform the requested operation.

5. Replying to Client:

o The server stub marshals the return values into a reply message.

o The reply message is sent back to the client.

6. Client Reception: The client stub receives the reply message and unmarshals the return
values for the client program to use.

Invocation Semantics

RPC can be designed with different invocation semantics, typically either:

  At-least-once: Ensures that the operation is performed at least once, which may result in
duplicate executions.

 At-most-once: Ensures that the operation is executed no more than once, which may result
in some operations not being executed if a failure occurs.

To implement these semantics, the communication module must handle:

 Retransmissions of requests in case of timeouts.

 Detection and handling of duplicate requests.

 Retransmission of results when necessary.

Automatic Generation of Stubs

The client and server stub procedures, as well as the dispatcher, can often be generated
automatically from an interface definition using an interface compiler. This automation simplifies the
development process and ensures consistency in how RPC calls are made and handled.

Conclusion

RPC provides a powerful mechanism for enabling communication between distributed systems. By
abstracting the complexity of remote interactions into simple procedure calls, it allows developers to
build distributed applications more easily. The careful design of the stub procedures and
communication modules, along with consideration of invocation semantics, is essential for creating a
robust RPC system.

Case Study: Sun RPC (ONC RPC)

Sun RPC, also known as ONC RPC (Open Network Computing Remote Procedure Call), was designed
primarily for client-server communication in the Sun Network File System (NFS). This case study
outlines its key features, components, and operational mechanisms.

Overview of Sun RPC

 Designed for NFS: Sun RPC facilitates communication between clients and servers in the NFS
environment.

 Protocol Options: It can operate over both UDP (User Datagram Protocol) and TCP
(Transmission Control Protocol).

o UDP Limitations: When using UDP, the maximum length for request and reply
messages is theoretically 64 kilobytes but practically limited to around 8 or 9
kilobytes.

 Invocation Semantics: Sun RPC utilizes at-least-once semantics, ensuring that a call is
executed at least once, which can lead to duplicate executions if a response is lost.

 Broadcast RPC: Sun RPC supports the option for broadcast RPC, allowing clients to send
requests to multiple servers.

Key Components
 1. Interface Definition Language (IDL):

o XDR (External Data Representation): Initially designed for external data

representation, XDR was extended to serve as the IDL for defining service interfaces
in Sun RPC.

o Primitive Syntax: XDR is more primitive compared to more advanced IDLs like CORBA
IDL or Java IDL.

o Program and Version Numbers: Instead of named interfaces, XDR requires the use of
a program number (registered with a central authority) and a version number to
manage service versioning.

o Structure Limitations: Each procedure can accept only a single input parameter,
necessitating the use of structures for procedures that require multiple parameters.

Example Interface Definition (Figure 5.11):

Copy code

const MAX = 1000;

typedef int FileIdentifier;

typedef int FilePointer;

typedef int Length;

struct Data {

int length;

char buffer[MAX];

};

struct writeargs {

FileIdentifier f;

FilePointer position;

Data data;

};

struct readargs {

FileIdentifier f;

FilePointer position;
 Length length;

};

program FILEREADWRITE {

version VERSION {

void WRITE(writeargs) = 1;

Data READ(readargs) = 2;

} = 2;

} = 9999;

2. Interface Compiler (rpcgen):

o Generated Code: The rpcgen tool generates:

 Client stub procedures

 Server main procedure and dispatcher

 Server stub procedures

 XDR marshalling and unmarshalling routines

3. Binding Service (Port Mapper):

o Local Binding: Each computer runs a port mapper at a well-known port number,
which records the program number, version number, and port number of each
locally running service.

o Service Registration: Upon startup, services register their details with the local port
mapper.

o Client Discovery: Clients query the port mapper to find the correct port for a service
based on its program and version numbers.

o Multicasting: For services with multiple instances, clients can multicast requests to
all port mappers, which then route the calls to the appropriate local services.

4. Authentication:

o Credentials in Requests: Sun RPC allows the passing of authentication information

(e.g., user ID and group ID in UNIX-style authentication) in the request message.

o Access Control: The server is responsible for enforcing access control based on the
authentication information provided.

o Supported Authentication Protocols:

 None

 UNIX-style
  Shared-key signing

 Kerberos

5. Security:

o Sun RPC can implement additional security measures to ensure message integrity
and confidentiality.

o RFC 2203 outlines a more generic approach to security, allowing negotiation of

security contexts for message integrity or privacy.

Client and Server Programs

Sun RPC comes with example client and server programs that illustrate how to implement interfaces
defined using the XDR language. These examples help developers understand how to work with Sun
RPC in practice.

Remote Method Invocation (RMI) is a Java-based technology that allows objects running in different
Java Virtual Machines (JVMs) to communicate with each other as if they were in the same JVM. This
mechanism enables the development of distributed applications where clients can invoke methods
on remote objects hosted on a server, making it a key component for building networked
applications in Java.

Key Features of RMI

1. Object-Oriented: RMI is built around the object-oriented paradigm, allowing remote

methods to operate on objects, thereby maintaining the object-oriented nature of Java.

2. Location Transparency: Clients can invoke methods on remote objects without needing to
know the details of their location, whether they are on the same machine or on a different
machine across a network.

3. Automatic Marshalling/Unmarshalling: RMI automatically handles the serialization of

method parameters and return values when communicating over the network, making it
easier for developers to work with complex data types.

4. Dynamic Discovery: RMI provides mechanisms for discovering remote objects at runtime,
allowing flexibility in how client applications locate and interact with remote services.

5. Integration with Java Security: RMI can be secured using Java's security manager and policy
files, enabling fine-grained control over what operations are allowed for remote method
calls.

Key Components of RMI

1. Remote Interface: This defines the methods that can be invoked remotely. It must extend
java.rmi.Remote and each method must throw a RemoteException.

java

Copy code
import java.rmi.Remote;

import java.rmi.RemoteException;

public interface RemoteService extends Remote {

String sayHello() throws RemoteException;

2. Remote Object Implementation: This class implements the remote interface and defines the
actual behavior of the remote methods.

java

Copy code

import java.rmi.server.UnicastRemoteObject;

import java.rmi.RemoteException;

public class RemoteServiceImpl extends UnicastRemoteObject implements RemoteService {

protected RemoteServiceImpl() throws RemoteException {

super();

@Override

public String sayHello() throws RemoteException {

return "Hello from the server!";

3. RMI Registry: This is a simple naming service that allows clients to look up remote objects by
name. The registry runs on a specific port (default is 1099).

java

Copy code

import java.rmi.registry.LocateRegistry;

import java.rmi.registry.Registry;

public class Server {

public static void main(String[] args) {

 try {

RemoteService service = new RemoteServiceImpl();

Registry registry = LocateRegistry.createRegistry(1099);

registry.bind("RemoteService", service);

System.out.println("Server is ready.");

} catch (Exception e) {

e.printStackTrace();

4. Client: The client looks up the remote object in the RMI registry and invokes its methods.

java

Copy code

import java.rmi.registry.LocateRegistry;

import java.rmi.registry.Registry;

public class Client {

public static void main(String[] args) {

try {

Registry registry = LocateRegistry.getRegistry("localhost");

RemoteService service = (RemoteService) registry.lookup("RemoteService");

String response = service.sayHello();

System.out.println(response);

} catch (Exception e) {

e.printStackTrace();

RMI Workflow

1. Define a Remote Interface: Create an interface that declares the remote methods.
 2. Implement the Remote Interface: Write a class that implements the remote interface,
providing the logic for the remote methods.

3. Create the RMI Registry: Start the RMI registry and bind the remote object to it.

4. Client Lookup: The client locates the remote object via the RMI registry and invokes methods
on it.

5. Serialization: RMI automatically handles the serialization of method parameters and return
values, allowing complex objects to be sent over the network.

Error Handling

RMI employs several exceptions to handle errors that may occur during remote method invocation:

 RemoteException: Indicates a failure during the remote method call.

 NotBoundException: Thrown when an attempt is made to access a name that has not been
bound in the registry.

 AlreadyBoundException: Thrown when an attempt is made to bind a name to a remote

object that is already bound.

Security

RMI can be secured using the Java Security Manager, which allows developers to specify what
resources (like file systems or network connections) remote objects can access. The security policy
can be defined in a policy file, which the Java application uses at runtime.

Conclusion

RMI provides a powerful and flexible mechanism for building distributed applications in Java. By
allowing remote method invocation in a manner that feels local, RMI simplifies the complexity of
network programming and enables the development of sophisticated networked applications. The
automatic handling of serialization and integration with Java's security model further enhances its
usability for developers.