MAHAKAL INSTITUTE OF

TECHNOLOGY
BEHIND AIR STRIP UJJAIN (MP)
Approved By All India Council of Technical Education
(New Delhi)

DEPARTMENT OF COMPUTER
SCIENCE AND ENGINEERING

Distributed Operating systems

(CS-7001)

LAB - MANUAL

Affiliated to Rajiv Gandhi Prodyogiki Vishwavidyalaya Bhopal

(MP)
 INDEX

DISTRIBUTED OPERATING SYSTEMS(CS-7001)

S.N NAME DATE REMARK

O OF OF
EXPERIMENT SUBMISSION
1 Case Study – CORBA.

2 Case Study on Inventory Management

3 Case Study on Supply Chain Management

4 Case Study on Reservation System

5 Case Study on University Counseling

6 Case Study on Online Chain Management

7 Implementation of Election Algorithm.

8 S/W Simulation for Clock Synchronization

in Distributed System using Lamport’s
Algorithm.
9 Implementation of Banker’s Algorithm for
avoiding Deadlock.
10 Implementation of Deadlock through
Simulation.
 List of the Experiments

DISTRIBUTED OPERATING SYSTEMS (CS-703)

1. Case Study – CORBA and implementation of RMI.

2. Case Study on Inventory Management.

3. Case Study on Supply Chain Management.

4. Case Study on Reservation System.

5. Case Study on University Counseling.

6. Case Study on Online Chain Management.

7. Implementation of Election Algorithm.

8. S/W Simulation for Clock Synchronization in Distributed

System using Lamport’s Algorithm.

9. Implementation of Banker’s Algorithm for avoiding

Deadlock.

10. Implementation of Deadlock through Simulation.

 PROGRAM NO: - 1

PROBLEM DEFINITION:
Case study on CORBA and implement of RMI.

OBJECTIVE:
Client and RMI Server Implementation and The RMI application comprises of the two separate
programs, a server and a client. A typical server program creates some remote objects, makes
references to these objects accessible, and waits for clients to invoke methods on these objects.
The RMI application provides the mechanism by which the server and the client communicate
and pass information back and forth. The RMI distributed application uses the RMI Registry to
obtain a reference to a remote object. The server calls the registry to associate a name with a
remote object. The client looks up the remote object by its name in the server’s registry and then
invokes a method on it.

CONTENT:
a. Introduction
b. Basic Interface
c. CORBA architecture
d. The object request broker
e. IDL
f. Java RMI
g. Implement of RMI

INPUTSET:
In this section, you will learn how to send massage from RmiClient to the RmiServer. Here, we
are going to create "ReceiveMessageInterface" interface. The interface defines the methods that
can be invoked from the client. Essentially, the interface defines the client's view of the remote
object. After that, we will create a class named "RMIServer". The RMI Server accepts tasks from
clients, runs the tasks, and returns any result. The server code consists of an interface and a
class.

In this class, the “receiveMessage()” method, which is called from the remote client, is defined.
This class is the implementation of the RMI interface. The RmiServer creates the “registry”. This
is a kind of directory. Its key is a name (which is the ID of a remote object) and its content is an
object. This object is looked up from a remote program by the name. This registry is accessed
from a remote object by the IP address or host name and the port number.

createRegistry(): This is the method creates and exports a registry on the local host that accepts
requests on the specified port.
ReceiveMessageInterface.java
import java.rmi.*;
public interface ReceiveMessageInterface extends Remote{
void receiveMessage(String x) throws RemoteException;
}
The above code defines the RMI interface. The receiveMessage() method is implemented in the
server class.
Here is the code of RMI Server:
import java.rmi.*;
import java.rmi.registry.*;
import java.rmi.server.*;
import java.net.*;

public class RmiServer extends

java.rmi.server.UnicastRemoteObject implements ReceiveMessageInterface{
String address;
Registry registry;
public void receiveMessage(String x) throws RemoteException{
System.out.println(x);
}

public RmiServer() throws RemoteException{

try{
address = (InetAddress.getLocalHost()).toString();
}
catch(Exception e){
System.out.println("can't get inet address.");
}
int port=3232;
System.out.println("this address=" + address + ",port=" + port);
try{
registry = LocateRegistry.createRegistry(port);
registry.rebind("rmiServer", this);
}
catch(RemoteException e){
System.out.println("remote exception"+ e);
}
}
static public void main(String args[]){
try{
 RmiServer server = new RmiServer();
}
catch (Exception e)
{
e.printStackTrace();
System.exit(1);
}
}
}
The above class uses LocateRegistry class to create a remote object registry that accepts calls on
a specific port.
Output of the above program:

C:\rose>javac RmiServer.java
C:\rose>java RmiServer
this address=roseindi/192.168.10.104,port=3232t=
_3232

Here is the code of RMI Client:

import java.rmi.*;
import java.rmi.registry.*;
import java.net.*;

public class RmiClient

{
static public void main(String args[])
{
ReceiveMessageInterface rmiServer;
Registry registry;
String serverAddress=args[0];
String serverPort=args[1];
String text=args[2];
System.out.println
("sending " + text + " to " +serverAddress + ":" + serverPort);
try{
registry=LocateRegistry.getRegistry
(serverAddress,(new Integer(serverPort)).intValue());
rmiServer=(ReceiveMessageInterface)(registry.lookup("rmiServer"));
// call the remote method
rmiServer.receiveMessage(text);
}
catch(RemoteException e){
e.printStackTrace();
 }
catch(NotBoundException e)
{
System.err.println(e);
}
}
}
lookup(): This is the method that returns a reference, a stub, for the remote object associated with
the specified name.

OUTPUT SET:

C:\rose>java RmiClient 192.168.10.104 3232 roseindia

sending roseindia to 192.168.10.104:3232

C:\rose>

If the RMI client sends any type of massage then massage will be displayed on the RMI Server.

C:\rose>java RmiServer
this address=roseindi/192.168.10.104,port=3232
roseindia

NOTES:

NAME OF FACULTY:
SIGNATURE:
DATE:
 PROGRAM NO: - 2

PROBLEM DEFINITION:
Case study on Inventory management.

OBJECTIVE:
Case study on Inventory management.

CONTENT:
a. Introduction
b. Process Management
c. Memory Management
d. Communication
e. Conclusion

INPUT SET:

OUTPUT SET:

NOTES:

NAME OF FACULTY:
SIGNATURE:
DATE:
 PROGRAM NO: - 3

PROBLEM DEFINITION:
Case study on Supply chain Management

OBJECTIVE:
Case study on Supply chain Management

CONTENT:
a. Introduction
b. Process Management
c. Memory Management
d. Communication
e. Conclusion

INPUT SET:

OUTPUT SET:

NOTES:

NAME OF FACULTY:
SIGNATURE:
DATE:
 PROGRAM NO: - 4

PROBLEM DEFINITION:
Case study on Railway Reservation system

OBJECTIVE:
Case study on Railway Reservation system

CONTENT:
a. Introduction
b. Process Management
c. Memory Management
d. Communication
e. Conclusion

INPUT SET:

OUTPUT SET:

NOTES:

NAME OF FACULTY:
SIGNATURE:
DATE:
 PROGRAM NO: - 5

PROBLEM DEFINITION:
Case study on University Counseling.

OBJECTIVE:
Case study on University Counseling.

CONTENT:
a. Introduction
b. Process Management
c. Memory Management
d. Communication
e. Conclusion

INPUT SET:

OUTPUT SET:

NOTES:

NAME OF FACULTY:
SIGNATURE:
DATE:
 PROGRAM NO: - 6

PROBLEM DEFINITION:
Case study on Online Chain Management.

OBJECTIVE:
Case study on Online Chain Management.

CONTENT:
a. Introduction
b. Process Management
c. Memory Management
d. Communication
e. Conclusion

INPUT SET:

OUTPUT SET:

NOTES:

NAME OF FACULTY:
SIGNATURE:
DATE:
 PROGRAM NO: - 7
PROBLEM DEFINITION:
Implementation of Election Algorithms.

OBJECTIVE:
The Election Algorithm is a method in distributed computing for dynamically selecting a
coordinator by process ID number.

ALGORITHMS:
Selects the process with the largest identifier as the coordinator:
1. When a process p detects that the coordinator is not responding to requests, it
initiates an election:
a. p sends an election message to all processes with higher numbers.
b. If nobody responds, then p wins and takes over.
c. If one of the processes answers, then p's job is done.

2. If a process receives an election message from a lower numbered process at any time, it:
a. sends an OK message back.
b. holds an election (unless its already holding one).

3. A process announces its victory by sending all processes a message telling them that it is
the new coordinator.

4. If a process that has been down recovers, it holds an election.

Process 4 holds an election
Processes 5 and 6 respond, telling 4 to stop
Example:

At any moment, a process can get an ELECTION message from one of its lower-numbered
colleagues. When such a message arrives, the receiver sends an OK message back to the Sender
to indicate that he is alive and will take over. The receiver then holds an election, unless it is
already holding one. Eventually, all processes give up but one and that one is the new
coordinator. It announces it victory by sending all processes a message telling them that starting
immediately it is the new coordinator. If a process that was previously down comes back up, it
holds an election. If it happens to be the highest-numbered process currently running, it will win
the election and take over the co-coordinator’s job. Thus the biggest guy in town always wins,
hence the name “bully algorithm”. In the figure above we see an example of how the bully
algorithm works. The group consists of eight processes, numbered from 0 to 7. Previously
process 7 was the coordinator, but it has just crashed. Process 4 is the first one to notice this, so it
sends ELECTION messages to all the processes higher than it, namely 5, 6, and 7, as shown in
(a). Processes 5 and 6 both re-spond with OK, as shown in (b). Upon getting the first of these
responses, 4 know that its job is over. It knows that one of these bigwigs will take over and
become coordinator. It just sits back and waits to see who the winner will be (although at this
point it can make a pretty good guess). In (c), both 5 and 6 hold elections, each one only sending
message to those processes higher than itself. In (d) process 6 tells 5 that it will take over. At this
point 6 know that 7 is dead and that it (6) is the winner. If there is state information to be
collected from disk or elsewhere to pick up where the old coordinator left off, 6 must now do
what is needed. When it is ready to take over, 6 announce this by sending a COORDINATOR
message to all running processes. When 4 gets this message, it can now continue with the
operation it was trying to do when it discovered that 7 was dead, but using 6 as the coordinator
this time. In this way the failure of 7 is handled and the work can continue. If process 7 is ever
restarted, it will just send all the others a COORDINATOR message and bully them into
submission.

INPUT SET:
Bully election algorithm program

import java.io.*;
public class Bully {
static class Message {
String type; Participant candidate;
Message (String t, Participant p){
type=t; candidate=p;
}
}
static class Participant extends Thread{
MessageQueue inbox;
MessageQueue[] neighbour;
int value;
Participant boss;
Participant me;

public void run(){

boss=this; me=this;
(new Thread(){public void run(){

for(int i=0;i<neighbour.length;i++)

try{
neighbour[i].send(new Message("election",me));
}catch(Exception e){}}}).start();

try{for(;;){
Message m=(Message)inbox.receive();
System.out.println(value + " receives "

+ m.type+ " " + m.candidate.value);

if(m.type=="election"){
if(m.candidate.value>boss.value) boss=m.candidate;

}}catch(Exception e){}

public static void main(String[] args) throws IOException {

final int n = 9;

final int [] value = {11,9,17,6,15,19,2,12,7};

Participant[] part = new Participant[n];

MessageQueue[] q = new MessageQueue[n];

for(int i=0;i<n;i++){

part[i]=new Participant();

part[i].value=value[i];

q[i]=new MessageQueue(10);

for(int i=0;i<n;i++){

part[i].inbox=q[i];

part[i].neighbour=new MessageQueue[n];

for(int i=0;i<n;i++){

for(int j=0;j<n;j++){
part[i].neighbour[j]=part[j].inbox;

for(int i=0;i<n;i++){

part[i].start();
}

try{Thread.sleep(500);}catch(Exception e){}

for(int i=0;i<n;i++){

part[i].interrupt();

for(int i=0;i<n;i++){if(part[i].boss!=null)

System.out.println(part[i].value + " boss is " + part[i].boss.value);

OUTPUT:

NOTES:
NAME OF FACULTY:
SIGNATURE:
DATE:
 PROGRAM NO: - 8
PROBLEM DEFINITION:
S/W Simulation for Clock Synchronization in Distributed System using Lamport’s Algorithm.

OBJECTIVE:
S/W Simulation for Clock Synchronization in Distributed System using Lamport’s Algorithm.

ALGORITHMS:
To synchronization logical clocks, Lamport defined the relation called happens-before. The
expression a→b is read “a happened before b” and means that all processes agree that first event
a occurs then afterward event b occurs. This relation can be expiation directly two situations:
1. If a and b are events in the same process and a occurs before b, then a→b is true.
2. If a is the events of a message being sent by one process, and b is the events of the message
being received by another process Then a→b is also true. Let us look at the algorithms Lamports
proposed for assigning times to events .consider the three processes shown in fig. The Processes
run on different m/c each with its own clock, running at its own speed as can be seen from the
fig. when the clock has Ticked 6 times in process p1, it has ticked 8 times in process p2 and 10
times in process p3.

0 0 0
M1
6 1 8 10

12 16 20
M2
18 24 1 30

24 32 40

30 40 50
M3
36 48 1 60

42 56 70
M4
48 1 64 80
54 72 90
60 80 100

P1 P2 P3

Three processes each with its own clock. The clock runs at different rates.

At times 6, process P1 sends message m1 to processes p2. How long this message takes to
arrived depends on clock you beloved In any events the clock in process p2 reads 16 when it
arrives .if The message carries the starting time 6 in it if the message carries the starting time 6 in
it process p2 will conclude that it took 10 ticks to makes the journey .Now consider message
m3.It leaves process p3 at 60 and arrives. At P2 at 56.Similarly message m4 from p2 to p1
leaves at 64 and arrives at 54.these values are clearly impossible.

Lamport’s Soln: -
Follows directly from the happens-before relation. Since m3 left at 60 it must arrive at 61 or
later. Therefore, each message carries the sending time according to the sender’s clock. When a
message arrives and the receiver’s Clock shows a value prior to the time the message was sent,
the Receiver fast forwards its clock to be one more than the sending time. We see that m3 now
arrives at 61. Similarly, m4 arrives at 70.

0 M1 0 0
1
6 8 10

12 16 20
M2
18 24 1 30

24 32 40

30 40 50
M3
36 48 1 60

42 61 70
M4
48 1 69 80
70 77 90
76 85 100

P1 P2 P3

Consider the message as sent by the three processes shown in .Denote by Tsnd (mi) the logical
time at which message mi was sent and likewise, by Trcv(mi) the time of its receipt. We known
that for each message Tsnd (mi) <Trcv (mi).

Concurrent Message transmission using logical clock.

Vector Clocks:-

A Vector clock VC (a) assigned to an events a has a property that if VC(a)<VC(b) for some
event b, then event a is known to casually precede event b. Vector clocks are constructed by
letting each process Pi maintain a Vector VCi with the following two properties.

1.VCi[i] is the number of event that have occurred so far at Pi. In other words ,VCi[i] is the local
logical clock at process Pi.

2.If VCi[j]=k then Pi knows that k events have occurred at Pj. It is thus Pi’s knowledge of the
local time at Pj.
The first property is maintained by incrementing VCi[i] at the occurrence of each new event that
happens at process Pi. The Second property is maintained piggybacking vector along with
Messages that are sent.

1) Before executing an event (i.e. sending a message over the network, delivering a message to
an application, or some other
Internal event Pi executes VCi[i]-->VCi[i]+1.

2) When process Pi sends a message m to Pj ,it sets m’s (vector)

Time stamp ts(m) equal to VCi.

3) Upon the receipt of a message m, process Pj adjusts its own vector by setting VCj[k]←max
{VCj[k],ts(m)[K]} for each k
After which it execute the first step and delivers the message to the application.

INPUT:

OUTPUT:

NOTES:

NAME OF FACULTY:
SIGNATURE:
DATE:
 PROGRAM NO: - 9
PROBLEM DEFINITION:
Implementation of Deadlock through Simulation.

OBJECTIVE:
To Understanding the Concept Deadlock through Simulator.

ALGORITHME:
Simulation modeling and analysis has long been a major tool in the operational analysis of
manufacturing systems. A subtle and often problematic aspect of simulation that has not been
adequately addressed is deadlocking. Currently available commercial simulation systems provide
no tools for detecting or resolving deadlocks. procedures to detect and resolve simulation
deadlocks under conditions of single-unit resource requests, and provide implementation and
computational experience with the MOR/DS (Curry et al. [4]) simulation package. Deadlock
occurs in simulation systems due to the dynamic interaction of entities and resources in The
course of the simulation. Use a graph formalism that represents this dynamic interaction to
define deadlock characteristics in discrete simulation systems. The Procedure presented detects
and resolves deadlocks under the condition that entities are restricted to single-unit resource
requests. A distinction is made between self-resolvable and nonselfresolvable deadlocks in
simulation systems. Self-resolvable deadlocks are called transient Deadlocks, whereas non self-
resolvable deadlocks are called permanent deadlocks the re-introduction of additional resource
units into the simulation can allow other Deadlocked entities to use the freed resource and,
consequently, relieve the blockage situation in the simulation.

Example 1.
Consider a manufacturing process with a unit capacity machine (r2) that requires an operator (r1)
for loading and unloading of jobs. Figure shows the evolution of a simulation that leads to a
deadlock. The simulation of the manufacturing process assumes that a part in control of either of
the resources will not relinquish control of the resource it is holding until its request has been
granted. In Figure 4a, job 1 (e1) has control of the operator (r1) so that it can be loaded on the
machine (r2), while job 2 (e2) is being processed on the machine. In Figure b, job 1 has
requested the Machine (r2), which creates a new edge from e1 to r2. In Figure c, job 2 has
finished processing 6 on the machine and requests the operator to unload the machine. This event
creates an edge from to e2 to r1. Since neither entity will relinquish the resource that it controls
until its respective request has been granted, the simulation is deadlocked, and the two jobs will
wait indefinitely. Furthermore, any other entities requesting either resource will also wait
indefinitely. The simulation system as shown in Figure 4c is said to be in total deadlock.
 Deadloc Transient Pending Total-
- - Deadlock
k Self
Deadlo Deadloc
Free
resolvable
ck k
Deadlock
State

Nonself-resolvable
Deadlock
Deadlock States
Free State

1. Transition diagram for simulation deadlock states.

a) r k e k r
e

K resource units Entity waiting for

Assigned to entity K resource Unit

2. Entity-resource relationship scheme - (a) assignment edge, (b) request

or queue edge.

a) r1 k e1 r2 e2
b) r1 k r2
e
e1 2

c) r1 r2
e1 e2

3. Sequence of events in Example 1 that leads to deadlock.

a. Definition of the enhanced seizes statement.

Seize (e,r,k) - entity e requests k units of resource r
1. if e V then
2. Insert (V,e);
3. if REQ[e,r] REM[r] then
4. Insert (E,(r,e,k));
5. REM[r] = REM[r] - REQ [e,r];
6. else
7. insert(E,(e,r,k));
8. if deadlock(r) 0 then
9. “Deadlock Detected”
10. Endif

b. Definition of the enhanced release statement.

Release (e,r,k) - entity e releases k units of resource r
1. delete(E,(r,e,k));
2. Delete (USES[r], e);
3. REM[r] = REM[r] + k;
4. if OWNS[e] = Ø then
5. Delete (V,e);
6. if QUEUE[r] Ø then
7. e’ = firstfit(r);
8. if e’ Ø then
9. Dowhile (e’ Ø)
10. delete(E,(e’,r,REQ[e’,r]));
11. Insert (E,(r,e’,REQ[e’,r]));
12. REM[r] = REM[r] - REQ [e’, r];
13. e’ = firstfit(r);
14. End while
15. Else
16. if PENDING_IGNORED then
17. if deadlock(r) = 3 then “ total deadlock ”
18. “Deadlcok Detected”
19. Endif

INPUT:

OUTPUT:

NOTES:

NAME OF FACULTY:
SIGNATURE:
DATE:
 PROGRAM NO: - 10
PROBLEM DEFINITION:
Implementation of Banker’s Algorithms for avoiding a Deadlock.

OBJECTIVE:
Implementation of Banker’s Algorithms for avoiding a Deadlock.

ALGORITHMS:
Several data structure must be maintained to implement the banker’s algorithms. Let n be the
number of processes in the system and m be the number of resource types.

*Available: - A vector of length m indicates the number of

Available resources of each type. If Available[j] equals k, there
Are k instances of resource type Rj available.

*Max:- An n*m matrix defined the maximum demand of each

Process if Max[i][j] equals k, then process Pi may request at
Most k instances of resource type Rj.

*Allocation: - An n*m matrix defined the maximum demand of

Each Type currently allocated to each process. If Allocation [i][j] equals k then process Pi is
currently allocated k instances
Of resource type Rj.

*Need:- An n*m matrix indicates the remained resource need of each process if Need[i][j] equals
to k then process Pi may need
K more instances of resource type Rj to computed its task

Safety Algorithms
1. Let Work and Finish be vector of length m and n respectively
Work=Available and Finish[i]=false for i=0,1……,n-1.

2. Find an i such that both

a. Finish[i]==false
b.Needi<=Work

3. Work =Work+Allocation
Finish[i]=true
Go to step 2
4.If Finish[i] = =true for all i then the system is in a safe state.

Resource-Request Algorithms:
Let Requesti be the request vector for process Pi. If Requesti[j]== k then process Pi wants k
instances of resource type Rj. When a request for resources is made by process Pi
The following actions are taken:

1.If Requesti<= Needi go to step2. Otherwise raises an error condition, since the process has
exceeded its maximum claim.

2. If Requesti <= Available go to step3 Otherwise Pi must wait

Since the resource are not available.
3. Have the system pretend to have allocated the requested resources to process Pi by modifying
the safe as follows:

Available=Available -Requesti
Allocationi=Allocationi+Requesti
Needi=Needi-Requesti

INPUT:

OUTPUT:

NOTES:

NAME OF FACULTY:
SIGNATURE:
DATE: