What are the two models of interprocess communication what are the strengths and weaknesses of the two

approaches?

One is message-passing model and the other is shared-memory model. Message-passing strengths and weaknesses:message can be exchanged between the processes either directly or indirectly through a common mailbox.it is userful for exchanging smaller amounts of data and easier to implement for intercomputer communication.however,its speed is slower than shared-memory model. Shared-memory strengths and weaknesses:it allows maxmum speed and convenience of communication.however,in the areas of protection and synchronization between the processes some problems exist.

Why would you design a system as a distributed system? List some advantages of distributed systems. Performance: very often a collection of processors can provide higher performance (and better price/performance ratio) than a centralized computer. Distribution: many applications involve, by their nature, spatially separated machines (banking, commercial, automotive system). Reliability (fault tolerance): if some of the machines crash, the system can survive. Incremental growth: as requirements on processing power grow, new machines can be added incrementally. Sharing of data/resources: shared data is essential to many applications (banking, computer supported cooperative work, reservation systems); other resources can be also shared (e.g. expensive printers). Communication: facilitates human-to-human communication. Write short notes on 1. Data Marshaling 2. Iterative server and concurrent server Marshalling is the process of transforming the memory representation of an object to a data format suitable for storage or transmission, and it is typically used when data must be moved between different parts of a computer program or from one program to another. Marshalling is similar to serialization and is used to communicate to remote objects with an object, in this case a serialized object. It simplifies complex communication, using custom/complex objects to communicate instead of primitives. Iterative server A server process may respond to incoming connections in two different ways. The first response pattern looks like this: 1. The server receives the incoming connection.

2. The server handles the connection. 3. The server closes the connection. 4. The server returns to listening on its well-known port. A server that operates like this is called an iterative server. When an iterative server is handling a request, other connections to that port are blocked. The incoming connections must be handled one after another. For example, a system in which the telnet server is set up as an iterative server can handle only one incoming telnet connection at a time. Concurrent server The second type of response pattern looks like this: 1. The server receives the incoming connection. 2. The server calls fork() to split itself into two processes, a parent and a child. 3. The child process handles the connection, while the parent returns to listen on the original port. 4. When the child process is finished with the connection, it terminates. A server that operates like this is called a concurrent server. A concurrent server is always available for incoming connections. For example, a system in which the telnet server is set up as a concurrent server can handle multiple telnet connections, each of which is managed by a different child of the listening server process.

What if the two computers use different representation for data (integers, chars, floating point)? The most elegant and flexible solution is to have a standard representation used for all values sent through the network; the proxy and skeleton convert to/from this representation during marshalling/unmarshalling.

Briefly state the differences between RPC and RMI. Asking for a service is solved by the client issuing a simple method invocation or procedure call; because the server can be on a remote machine this is a remote invocation (call). - RMI (RPC) is transparent: the calling object (procedure) is not aware that the called one is executing on a different machine, and vice versa. Explain the model of group communication. State the reason why do we need it. With group communication a message can be sent to multiple receivers in one operation, called multicast. Why do we need it?

 Special applications: interest-groups, mail-lists, etc. Fault tolerance based on replication: a request is sent to several servers which all execute the same operation (if one fails, the client still will be served). Locating a service or object in a distributed system: the client sends a message to all machines but only the one (or those) which holds the server/object responds . Replicated data (for reliability or performance): whenever the data changes, the new value has to be multicast to all processes managing replicas. Develop a Remote Factorial application that works as follows: The client program inputs One integer from the user and send the value to the server. The server finds the factorial of the integer and sends back the result of the operation to the client. The client displays the result to the user. import java.io.*; import java.net.*; class FactorialClient { public static void main(String arg[]) { int port=9999; Socket s; String msg=""; try { BufferedReader br=new BufferedReader(new InputStreamReader(System.in)); InetAddress addr=InetAddress.getByName(null); s=new Socket(addr,port); OutputStreamWriter osw=new OutputStreamWriter(s.getOutputStream()); PrintWriter pw=new PrintWriter(osw); BufferedReader br1=new BufferedReader(new InputStreamReader(s.getInputStream())); System.out.print("Enter a Number : "); String str=br.readLine(); pw.println(str); pw.flush(); msg=br1.readLine(); System.out.println("Answer from server : "); System.out.println(msg); } catch(Exception e)

{ } }}

import java.io.*; import java.net.*; class FactorialServer implements Runnable { Socket s; int id; public static void main(String arg[]) { int port=9999,count=0; try { // create new socket ServerSocket ss=new ServerSocket(port); System.out.println("Waiting for client"); while(true) { Socket s=ss.accept(); FactorialServer serve=new FactorialServer(s,count); // launch new thread Thread t=new Thread(serve); t.start(); } } catch(Exception e) { // Ignore error System.out.println("Error"); } }

FactorialServer(Socket s,int id) { this.s = s;

this.id = id; } public void run() { try { BufferedReader br=new BufferedReader(new InputStreamReader(s.getInputStream())); PrintWriter pw=new PrintWriter(new OutputStreamWriter(s.getOutputStream())) ; String str=br.readLine(); int n=Integer.parseInt(str); int i; long f=1; System.out.println("Number sent by client: " + n); for(i = 2; i <= n; i++) f = f * i; pw.println("Factorial is : "+f); pw.flush(); } catch(Exception e) { System.out.println("Thread: Error"); }}} Explain where and How do we use Stream mode sockets and Datagram sockets. A socket programming construct can use either UDP or TCP transport protocols. Sockets that use UDP for transport of packets are called datagram sockets and sockets that use TCP for transport are called stream sockets. Steps in Connectionless Datagram Socket Sender Program Create a DatagramSocket object and bind it to any local port; Place the data to send in a byte array; Create a DatagramPacket object, specifying the data array and the receivers address; Invoke the send method of the DatagramSocket object and pass as argument, a reference to the Receiver Program Create a DatagramSocket object and bind it to a specific local port; Create a byte array for receiving the data; Create a DatagramPacket object, specifying the data array. Invoke the receive method of the socket with a reference to the DatagramPacket object.

DatagramPacket object.

The Connection-Oriented (Stream-Mode) Socket The Connection-Oriented Sockets are based on the stream-mode I/O model of the UNIX Operating System data is transferred using the concept of a continuous data stream flowing from a source to a destination. Data is inserted into the stream by a sender process usually called the server and is extracted from the stream by the receiver process usually called the client. The server process establishes a connection socket and then listens for connection requests from other processes. Connection requests are accepted one at a time. When the connection request is accepted, a data socket is created using which the server process can write or read from/to the data stream. When the communication session between the two processes is over, the data socket is closed and the server process is free to accept another connection request. Note that the server process is blocked when it is listening or waiting for incoming connection requests. This problem could be alleviated by spawning threads, one for each incoming client connection request and a thread would then individually handle the particular client. Develop a simple RMI remote object for bank account. Create an Account object that represents some kind of bank account and then use RMI to export it as a remote object so that remote clients can access it and carry out transactions. A Remote Account Interface import java.rmi.Remote; import java.rmi.RemoteException; import java.util.List; public interface Account extends Remote { public String getName() throws RemoteException; public float getBalance() throws RemoteException; public void withdraw(float amt) throws RemoteException; public void deposit(float amt) throws RemoteException; public void transfer(float amt, Account src) throws RemoteException; public void transfer(List amts, List srcs) throws RemoteException; }

Implementation of the Remote Account Interface import java.rmi.server.UnicastRemoteObject; import java.rmi.RemoteException; import java.util.List; import java.util.ListIterator;

public class AccountImpl extends UnicastRemoteObject implements Account { private float mBalance = 0; private String mName = ""; // Create a new account with the given name public AccountImpl(String name) throws RemoteException { mName = name; } public String getName() throws RemoteException { return mName; } public float getBalance() throws RemoteException { return mBalance; } // Withdraw some funds public void withdraw(float amt) throws RemoteException { mBalance -= amt; // Make sure balance never drops below zero mBalance = Math.max(mBalance, 0); } // Deposit some funds public void deposit(float amt) throws RemoteException { mBalance += amt; } // Move some funds from another (remote) account into this one public void transfer(float amt, Account src) throws RemoteException { src.withdraw(amt); this.deposit(amt); } // Make several transfers from other (remote) accounts into this one public void transfer(List amts, List srcs) throws RemoteException { ListIterator amtCurs = amts.listIterator(); ListIterator srcCurs = srcs.listIterator(); // Iterate through the accounts and the amounts to be transferred from // each (assumes amounts are given as Float objects) while (amtCurs.hasNext() && srcCurs.hasNext()) { Float amt = (Float)amtCurs.next(); Account src = (Account)srcCurs.next(); this.transfer(amt.floatValue(), src); } }

import java.rmi.Naming; public class RegAccount { public static void main(String argv[]) { try { // Make an Account with a given name AccountImpl acct = new AccountImpl("JimF"); // Register it with the local naming registry Naming.rebind("JimF", acct); System.out.println("Registered account."); } catch (Exception e) { e.printStackTrace();

} }} import java.rmi.Naming; public class AccountClient { public static void main(String argv[]) { try { // Lookup account object Account jimAcct = (Account)Naming.lookup("rmi://objhost.org/JimF"); // Make deposit jimAcct.deposit(12000); // Report results and balance. System.out.println("Deposited 12,000 into account owned by " + jimAcct.getName()); System.out.println("Balance now totals: " + jimAcct.getBalance()); } catch (Exception e) { System.out.println("Error while looking up account:"); e.printStackTrace(); } }

Explain the Architecture of RMI with diagram There are three layers that comprise the basic remote-object communication facilities in RMI:

The stub/skeleton layer, which provides the interface that client and server application objects use to interact with each other. The remote reference layer, which is the middleware between the stub/skeleton layer and the underlying transport protocol. This layer handles the creation and management of remote object references. The transport protocol layer, which is the binary data protocol that sends remote object requests over the wire.

These layers interact with each other as shown in the diagram. In this figure, the server is the application that provides remotely accessible objects, while the client is any remote application that communicates with these server objects. In a distributed object system, the distinctions between clients and servers can get pretty blurry at times. Consider the case where one process registers a remote-enabled object with the RMI naming service, and a number of remote processes are accessing it. We might be tempted to call the first process the server and the other processes the clients. But what if one of the clients calls a method on the remote object, passing a reference to an RMI object that's local to the client. Now the server has a reference to and is using an object exported from the client, which turns the tables somewhat. The "server" is really the server for one object and the client of another object, and the "client" is a client and a server, too.

The RMI runtime architecture

Remote objects built with Java RMI are usually registered in a so called "registry". Why? Using Java RMI, applications can create remote objects that accept method calls from clients in other VMs. In order for a client to call methods on a remote object, the client must have a way to communicate with the remote object. Rather than having to program the client to speak the remote object's protocol, Java RMI uses special classes called stubs that can be downloaded to the client that are used to communicate with (make method calls on) the remote object. The java.rmi.server.codebase property value represents one or more URL locations from which these stubs (and any classes needed by the stubs) can be downloaded. Like applets, the classes needed to execute remote method calls can be downloaded , but like applets, a URL generally requires that the client and the server reside on the same physical host, unless the file system referred to by the URL is made available using some other protocol, such as NFS. Generally, the classes needed to execute remote method calls should be made accessible from a network resource, such as an HTTP or FTP server. 1. The remote object's codebase is specified by the remote object's server by setting the java.rmi.server.codebase property. The Java RMI server registers a remote object, bound

2.

3.

4.

5. 6.

to a name, with the Java RMI registry. The codebase set on the server VM is annotated to the remote object reference in the Java RMI registry. The Java RMI client requests a reference to a named remote object. The reference (the remote object's stub instance) is what the client will use to make remote method calls to the remote object. The Java RMI registry returns a reference (the stub instance) to the requested class. If the class definition for the stub instance can be found locally in the client's CLASSPATH , which is always searched before the codebase, the client will load the class locally. However, if the definition for the stub is not found in the client's CLASSPATH, the client will attempt to retrieve the class definition from the remote object's codebase. The client requests the class definition from the codebase. The codebase the client uses is the URL that was annotated to the stub instance when the stub class was loaded by the registry. Back in step 1, the annotated stub for the exported object was then registered with the Java RMI registry bound to a name. The class definition for the stub (and any other class(es) that it needs) is downloaded to the client. Now the client has all the information that it needs to invoke remote methods on the remote object. The stub instance acts as a proxy to the remote object that exists on the server; so unlike the applet which uses a codebase to execute code in its local VM, the Java RMI client uses the remote object's codebase to execute code in another, potentially remote VM, as illustrated in Figure 3: