EXPERIMENT NO.

Aim / Title: Multi-threaded client/server processes

Problem Statement: To write a Program for multi-threaded client/server processes

Objectives: Implement Multi-threaded client/server processes.

Outcomes: Student will be able to explain and implement Multi-threaded client/server processes.

Pre-requisite: : Socket programming using Python/ Java

Hardware requirements: Processor: 1 (GHz) RAM: 2 gigabyte (GB) for Hard disk space: 16 GB
.Graphics card: DirectX 9 or later with WDDM 1.0 driver,Display: 800x600.

Software requirements: Java /Linux

Theory: Multithreading is mainly found in multitasking operating systems. Multithreading is a
widespread programming and execution model that allows multiple threads to exist within the
context of a single process. These threads share the process's resources, but are able to execute
independently. The threaded programming model provides developers with a useful abstraction of
concurrent execution. Multithreading can also be applied to a single process to enable parallel
execution on a multiprocessing system.
Program:
import socket
from _thread import *
import threading
print_lock = threading.Lock()
def threaded(c):
while True:
data = c.recv(1024)
if not data:
print('Bye')
print_lock.release()
break
data = data[::-1]
c.send(data); c.close()
def Main():
host = ""
port = 12345
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

1|Page
 s.bind((host, port))
print("socket binded to port", port)
s.listen(5)
print("socket is listening")
while True:
c, addr = s.accept()
print_lock.acquire()
print('Connected to :', addr[0], ':',
addr[1]);start_new_thread(threaded, (c,))
s.close()
if __name__ == '__main__':
Main()
Output:

Client side:
import socket
def Main():
host = '127.0.0.1'
port = 12345
s = socket.socket(socket.AF_INET,
socket.SOCK_STREAM)
s.connect((host, port))
message = "shaurya says geeksforgeeks"

2|Page
 while True:
s.send(message.encode('ascii'))
data = s.recv(1024)
print('Received from the server :',
str(data.decode('ascii')))
ans = input('\nDo you want to continue(y/n) :')
if ans == 'y':
continue
else:
break
s.close()
if __name__ == '__main__':
Main()
Output:

Conclusion: Hence we have understood and run this multi-threaded client-server processes program
successfully.

3|Page
Sample Viva Questions and Answers:
Q1. What is Multi-threaded client/server processes?

Q2. How Does Thread Communicate With Each Other?

Q3. Explain About Thread Priority?

Q4. What Is Use Of Synchronized Keyword?

4|Page
Q5. What Is Time Slicing?

Sign of Sign of
Date of Date of Student Faculty
Roll.No Name of Students Performance Evaluation Grade

5|Page
6|Page
 EXPERIMENT NO :8

Aim / Title: To study Implementation of Mutual Exclusion algorithms

Problem Statement: Write a program to implement Mutual Exclusion algorithms

.
Objective: Implement Mutual Exclusion algorithms
.

Outcomes: Student will be able to implement and explain Mutual Exclusion algorithms.

Pre-requisite: Programming using Python/ Java

Hardware requirements:Processor: 1 (GHz) RAM: 2 gigabyte (GB) for Hard disk space: 16 GB
.Graphics card: DirectX 9 or later with WDDM 1.0 driver.Display: 800x600.
Software requirements: Python/ Java

Theory: In computer science, mutual exclusion refers to the requirement of ensuring that no
two concurrent processes are in their critical section at the same time; it is a basic requirement in
concurrency control, to prevent race conditions. Here, a critical section refers to a period when
the process accesses a shared resource, such as shared memory. The requirement of mutual
exclusion was first identified and solved by Edsger W. Dijkstra in his seminal 1965 paper titled
Solution of a problem in concurrent programming control, and is credited as the first topic in the
study of concurrent algorithms.
Requirements of Mutual exclusion Algorithm:
 No Deadlock:
Two or more site should not endlessly wait for any message that will never arrive.
 No Starvation:
Every site who wants to execute critical section should get an opportunity to execute it
in finite time. Any site should not wait indefinitely to execute critical section while
other site are repeatedly executing critical section
 Fairness:
Each site should get a fair chance to execute critical section. Any request to execute
critical section must be executed in the order they are made i.e Critical section
execution requests should be executed in the order of their arrival in the system.
 Fault Tolerance:
In case of failure, it should be able to recognize it by itself in order to continue
functioning without any disruption.

Solution to distributed mutual exclusion:

Message passing is a way to implement mutual exclusion. Below are the three
approaches based on message passing to implement mutual exclusion in distributed
systems:

7|Page
 1. Token Based Algorithm:
 A unique token is shared among all the sites.
 If a site possesses the unique token, it is allowed to enter its critical section
 This approach uses sequence number to order requests for the critical
section.
 Each requests for critical section contains a sequence number. This
sequence number is used to distinguish old and current requests.
 This approach insures Mutual exclusion as the token is unique
 Example:
 Suzuki-Kasami’s Broadcast Algorithm
2. Non-token based approach:
 A site communicates with other sites in order to determine which sites
should execute critical section next. This requires exchange of two or more
successive round of messages among sites.
 This approach use timestamps instead of sequence number to order
requests for the critical section.
 When ever a site make request for critical section, it gets a timestamp.
Timestamp is also used to resolve any conflict between critical section
requests.
 All algorithm which follows non-token based approach maintains a logical
clock. Logical clocks get updated according to Lamport’s scheme
 Example:
 Lamport's algorithm, Ricart–Agrawala algorithm
3. Quorum based approach:
 Instead of requesting permission to execute the critical section from all
other sites, Each site requests only a subset of sites which is called
a quorum.
 Any two subsets of sites or Quorum contains a common site.
 This common site is responsible to ensure mutual exclusion
 Example:
 Maekawa’s Algorithm

Program
import socket
from _thread import *
import threading
print_lock = threading.Lock()
def threaded(c):
while True:
data = c.recv(1024)

8|Page
 if not data:
print('Bye')
print_lock.release()
break
data = data[::-1]
c.send(data); c.close()
def Main():
host = ""
port = 12345
s = socket.socket(socket.AF_INET,
socket.SOCK_STREAM)
s.bind(host, port)
print("socket binded to port", port)
s.listen(5)
print("socket is listening")
while True:
c, addr = s.accept()
print_lock.acquire()
print('Connected to :', addr[0], ':',
addr[1]);start_new_thread(threaded, (c,))
s.close()
if __name__ == '__main__':
Main()
Output:

9|Page
Conclusion:

Sample Viva Questions and Answers:

Q1. . Explain Mutual Exclusion algorithms in distributed systems?

Q2. What are the Requirements of Mutual exclusion Algorithm ?

10 | P a g e
Q3. What is Token Based Algorithm.

Q4. What is Non-token based approach?

Q5. Define Quorum based approach used in distributed systems.

Sign of Sign of
Date of Date of Student Faculty
Roll.No Name of Students Performance Evaluation Grade

11 | P a g e
 EXPERIMENT NO: 9

Aim / Title: CORBA to demonstrate object brokering

Problem Statement: Write a program using CORBA to demonstrate object brokering.

Objective: To Create a Component for retrieving stock market exchange information using
CORBA
.

Outcomes: Student will be able to implement and explain CORBA to demonstrate object brokering.

Pre-requisite: Socket programming using Python/ Java

Hardware requirements: NA

Software requirements: Python/ Java

Theory: The Common Object Request Broker Architecture (CORBA) is a standard developed by the
Object Management Group (OMG) to provide interoperability among distributed objects. CORBA is
the world's leading middleware solution enabling the exchange of information, independent of
hardware platforms, programming languages, and operating systems. CORBA is essentially a design
specification for an Object Request Broker (ORB), where an ORB provides the mechanism required for
distributed objects to communicate with one another, whether locally or on remote devices, written in
different languages, or at different locations on a network.

The CORBA Interface Definition Language, or IDL, allows the development of language and location-
independent interfaces to distributed objects. Using CORBA, application components can communicate
with one another no matter where they are located, or who has designed them. CORBA provides the
location transparency to be able to execute these applications.

CORBA is often described as a "software bus" because it is a software-based communications interface

through which objects are located and accessed. The illustration below identifies the primary
components seen within a CORBA implementation.

12 | P a g e
Interface Definition Language (IDL)

A cornerstone of the CORBA standards is the Interface Definition Language. IDL is the OMG standard
for defining language-neutral APIs and provides the platform-independent delineation of the interfaces
of distributed objects. The ability of the CORBA environments to provide consistency between clients
and servers in heterogeneous environments begins with a standardized definition of the data and
operations constituting the client/server interface. This standardization mechanism is the IDL, and is
used by CORBA to describe the interfaces of objects.

CORBA Programming Definitions

Within a CORBA development process, there are a number of unique terms specific to a CORBA
implementation. Developers may find our Glossary of Terms helpful in understanding a full CORBA
implementation.

Interoperability

The first version of CORBA provided the IDL and standard mappings to just a few languages, and as
the CORBA standard has matured, CORBA 2.0 added more language bindings (particularly C++ and
Java) as well as General Inter-ORB Protocol (GIOP). When a client calls a CORBA operation, the
client ORB sends a GIOP message to the server. The server ORB converts this request into a call on the
server object and then returns the results in a GIOP reply. This standard transfer syntax, specified by
the Object Management Group, allows the interoperability of ORB-to-ORB interaction and is designed
to work over any transport protocol meeting a minimal set of assumptions.

13 | P a g e
When GIOP is sent over TCP/IP, it is called Internet Inter ORB Protocol (IIOP). IIOP is designed to
allow different ORB vendors to interoperate with one another. An example of this interoperability
occurs when there is communication between an enterprise designed ORB, and a smaller real-time
application, utilizing a real-time ORB.

Object Management Group (OMG)

The OMG is a non-profit consortium created in 1989 to promote the theory and practice of object
technology for the development for distributed operating systems. The goal is to provide a common
architectural framework for object-oriented applications based on widely available interface
specifications. With a membership of over 800 members, representing large and small companies
within the computer industry, OMG leads the specification development efforts of CORBA, OMG IDL,
IIOP, OMA, UML, MOF, and CWM specifications.

The OMG does not produce software or implementation guidelines, only the specifications to which
OMG members respond to in Request For Information (RFI) and Requests for Proposals (RFP). By
managing these specifications, the OMG supports the adoption process for the member companies
interested in advancing the uses and applications of distributed object-oriented computing.

Procedure:
1. Define the IDL interface
2. Implement the IDL interface using idlj compiler
3. Create a Client Program
4. Create a Server Program
5. Start orbed.
6. Start the Server.
7. Start the client
Program
import sys, os
import CORBA, Fortune, Fortune__POA

FORTUNE_PATH = "/usr/games/fortune"

class CookieServer_i (Fortune__POA.CookieServer):

def get_cookie(self):
pipe = os.popen(FORTUNE_PATH)

14 | P a g e
 cookie = pipe.read()
if pipe.close():
cookie = "Oh dear, couldn't get a fortune\n"
return cookie

orb = CORBA.ORB_init(sys.argv)
poa = orb.resolve_initial_references("RootPOA")

servant = CookieServer_i()
poa.activate_object(servant)

print(orb.object_to_string(servant._this())

poa._get_the_POAManager().activate()
orb.run()
Output:

Conclusion: Hence we have studied and run Bully leader election algorithm successfully.

15 | P a g e
Sample Viva Questions and Answers:

Q1. What is CORBA.

Q2.What is Interface Definition Language ?

Q3. What Object Management Group (OMG)?

16 | P a g e
Q4. What is Interoperability ?

Q5. What is Real-time CORBA?

Sign of Sign of
Date of Date of Student Faculty
Roll.No Name of Students Performance Evaluation Grade

17 | P a g e
 EXPERIMENT NO: 10

Aim / Title: Railway Reservation System

Problem Statement: Case study on Railway Reservation System

Objectives: Describe Railway Reservation System in Distributed System.

Outcomes: Student will research the design of Railway Reservation System .

Pre-requisite: Basic knowledge of distributed system

Hardware requirements: PC

Software requirements: UML

Theory:

Railway Reservation System is a system used for booking tickets over internet. Any Customer
Can book tickets for different trains. Customer can book a ticket only if the tickets are available.
Customer searches for the availability of tickets then if the tickets are available he books the
tickets by initially filling details in a form. Tickets can be booked in two ways by i-ticket or by e-
ticket booking. In case of i-ticket booking customer can book the tickets online and the tickets are
couriered to Particular customer at their address. But in case of e-ticket booking and cancelling
tickets are booked and cancelled online sitting at the home and customer himself has to take print
of the ticket but in both the cases amount for tickets are deducted from customers account. For
cancellation of ticket the customer has to go at reservation office than fill cancellation form and
ask the clerk to cancel the ticket than the refund is transferred to customer account. After booking
ticket the customer has to check out by paying fare amount to The Customers are required to
register on the server for getting access to the database and query result retrieval. Upon
registration, each user has an account which is essentially the „view level‟ for the customer. The
account contains comprehensive information of the user entered during registration and permits
the customer to get access to his past reservations, enquire about travel fare and availability of
seats, make afresh reservations, update his account details, etc. The Railway Administrator is the
second party in the transactions. The administrator is required to login using a master password,
once authenticated as an administrator, one has access and right of modification to all the
information stored in the database at the server. This includes the account information of the
customers, attributes and statistics of stations, description of the train stoppages and physical
description of coaches, all the reservations that have been made, etc. The railway administrator
has the right to modify any information stored at the server Database.

Conclusion:

18 | P a g e
 1. Draw use case diagram for railway reservation system .

Sign of Sign of
Date of Date of Student Faculty
Roll.No Name of Students Performance Evaluation Grade

19 | P a g e