MULUNGUSHI UNIVERSITY

SCHOOL OF ENGINEERING AND TECHNOLOGY (SET)

MASTER OF SCIENCE IN COMPUTER SCIENCE

Name: Nanyangwe Leah Rachael

Student Id: 202208075

Course Name: Advanced Distributed Systems

Course Code: CSS5711

Lecturer: Dr. Muwanei

Task: Write code that simulates the operation of the Central Server algorith m.
Table of Contents
1.0 The Central Server Algorithm ................................................................................................ 1
1.1 Central Server Coordinator Election ....................................................................................... 1
1.2 How the Central Server Algorithm Work ................................................................................ 1
2.0 Program Design ..................................................................................................................... 2
2.1 The Bully Algorithm for Electing the Coordinator .................................................................. 2
2.2 Central Server Algorithm ....................................................................................................... 3
3.0 Implementation of the Central Server Algorithm .................................................................... 4
3.1 Election of the Coordinator .................................................................................................... 4
3.2 Request and Grant Message ................................................................................................... 4
3.3 First Come First Server Basis ................................................................................................. 5
3.4 Release Message .................................................................................................................... 5
3.5 Exit Operation........................................................................................................................ 6
4.0 Testing ................................................................................................................................... 6
4.1 What happens when a Coordinator Fails? ............................................................................... 6
4.2 Multiple Request.................................................................................................................... 6
4.3 When no Release Message is Received by the Coordinator..................................................... 7
5.0 Drawbacks of the Central Server Algorithm ........................................................................... 7
6.0 Conclusion............................................................................................................................. 8
7.0 References ............................................................................................................................. 9

i
1.0 The Central Server Algorithm

Is a distributed system that provide several processes access to a shared resource (Stumm and
Zhou 1990). When several processes access a shared resource at the same time, it slows the
processing of data and can cause the whole system to fail. Central server algorithm only allows
one process to access a shared resources at a time. This increases the performance of the system
and reduces failure.

1.1 Central Server Coordinator Election

The central server becomes a bottleneck when a dead coordinator cannot be detected (Patil and
Naik 2014). This could be due to a dead coordinator or when a process recovers from failure
and decide to hold up an election. In order to resolve this problem, a new coordinator has to be
chosen. The algorithm used in this simulation of the central server, is the bully algorithm. Each
process knows the process priority Id of all other processes. The process with the highest
priority Id is chosen as the coordinator. The messages used in this election are:

- Election message, and

- Coordinator message

If a process that initialise the election does not receive a response within a specified time
interval, then it wins election otherwise a process that respond with the highest priority Id
becomes the coordinator.

1.2 How the Central Server Algorithm Work

Central server processing on shared resource
In distributed systems the central server algorithm maintains all shared resources as shown in
figure 1 below. It accepts requests from the all nodes connected to the server and sends out
responses. There are 4 processes, before any process can send requests to access the shared
resource, one process has to be elected as a coordinator. The job of the coordinator is to
coordinate operations of all processes. The coordinator grants access to resources based on the
first come first serve basis. When a process wants to enter the critical section and perform
operations on a shared resource, it has to send a request message to the coordinator. If there are
no other processes in the critical section, the coordinator responds with a grant message to grant
a process access to a resource and mark it as the one using a shared resource. In this state all
other processes are blocked and cannot enter the critical section (Krzyzanowski 2017).

1
The blocked processes will remain on a queue until the process holding a resource release it.
The coordinate remains in the waiting mode, waiting for the release message from the process
currently holding a resource. When a process holding the shared resource sends the release
message, immediately the coordinator grants access to a resource to the queued process based
on a first come first server basis and the process continues (Wismüller 2022).

Figure 1: shared resources in a client server system (Dr. Rutuja Kadam 2023)

2.0 Program Design

2.1 The Bully Algorithm for Electing the Coordinator

Figure 2 demonstrate the bully algorithm used when electing a coordinator.

- Process N sends election message to all processes with the high priority Id.
- Process N waits for responses from process 0..P.
- Process P responds with the highest priority Id.
- Process N waits for coordinator message from process P.
- Process P becomes coordinator, and
- Process P send coordinator message to process 0..N.
- The election process ends with process P as the new coordinator.

2
 Figure 2: Bully Algorithm

2.2 Central Server Algorithm

Figure 3 below demonstrate the central server algorithm for shared resources

- Process N request to enter a critical section.

- Coordinator P sends a grant message to process N to enter critical section and perform
operations on a shared resource.
- Process N enters critical section and perform operations on a shared resource.
- Process N sends a release message to coordinator P to release a resource for the next
queued process.
- Process N exit the critical section.

3
 Figure 3: Central Server Algorithm

3.0 Implementation of the Central Server Algorithm

The central server algorithm was implemented with four (4) processes, of which one of the
processes became the coordinator. The job of the coordinator is to coordinate all operations of
the central server.

3.1 Election of the Coordinator

The coordinator is elected using the bully algorithm, where a process with the highest priority
Id is elected as the coordinator. The figure 4 below shows the steps that are carried out in
electing a coordinator.

Figure 4: Election of The Coordinator

3.2 Request and Grant Message

The elected coordinator is responsible for all request message, and grant message. The
coordinator accepts request messages from processes, and send grant messages to processes,
one at a time. Figure 5 below simulates the operations that take place at a central server.

Figure 5: Request and Grant Message

4
3.3 First Come First Server Basis

First come first serve basis is used as a mode when granting access to a shared resource. In
figure 6, process 1 and 2 requested to enter a critical section. Process 1 was granted access first
as it was the first process to request access to a resource.

Figure 6: First Come First Serve Basis

3.4 Release Message

When a process request to enter a critical section and there is another process in the cri tical
section, the coordinator denies access. The requesting process remain on a queue, waiting for
the release of the resource. The process holding a shared resource, has to send a release message
to the coordinator to release a shared resource for the next queued process. Figure 7 below
shows how the release message was sent by process 2 to the coordinator to release a shared
resource. When process 2 was still in the critical section and performing operation on a shared
resource, process 1 was on the queue, waiting for the release of a shared resource. When a
shared resource was released from process 2, process 1 was granted access to the critical
section.

Figure 7: Release Message

5
 3.5 Exit Operation

A process can only exit the critical section, once the coordinator releases a shared resource its
holding. A process holding a resource sends a release message to the coordinator to release a
resource. When the coordinator releases a resource, the process immediately exits the critical
section. Figure 8 demonstrate the exit operation.

Figure 8: Exit Operation

4.0 Testing

4.1 What happens when a Coordinator Fails?

If a coordinator fails, at least one process with a high priority Id should initialise an election to
elect a new coordinator. Figure 9 shows that process 3 failed and a new election was initiated
by process 2 to elect a new coordinator

Figure 9: Initialising Election

4.2 Multiple Request

The coordinator does not respond to processes when there is already a process in the critical
section. Once one process enters a critical section, it is marked by the coordinator and no other
process is given access to a shared resource. For example, in figure 10 below process 0 in a
critical section, when process 1 and 2 sent request to enter a resource. Process 1 and 2 remained
on a queue until a resource was released.

6
 Figure 10: Multiple Requests to Enter A Resource

4.3 When no Release Message is Received by the Coordinator

The coordinator only releases a resource, upon receiving a release message from a process
currently holding a resource. In figure 11, process 1 requested to enter a critical section. Not
until process 0 sent a release message to the coordinator to release a resource, then the
coordinator sent a grant message to process 1.

Figure 11: No Release Message is Received

5.0 Drawbacks of the Central Server Algorithm

- The central server algorithm has some drawbacks, in situations where there are more
processes.
- The processes cannot distinguish between being blocked and not getting a message
because the coordinator it down.
- The coordinator does not know if the process currently in the critical section has died,
is in infinite loop, or taking longer to release a resource (Krzyzanowski 2017).

7
6.0 Conclusion

The central server algorithm is a distributed system, where all shared resources are maintained
on a single server. All processes connected to a server are able to request for a resource and
perform operation on the resource. Only one process is allowed to use a shared resource at a
time.

Before a resource is accessed, the processes elect a coordinator among themselves, to

coordinate all operations on a server. In this simulation program, the bully algorithm was used
to elect the coordinator. A process with the highest priority Id was elected as the coordinator.
The coordinator handled the request messages and grant messages.

When a process sends a request message for a shared resource, the coordinator sends a grant
message to give a requesting process access to a resource. If there is already a process in the
critical section the coordinator ignores the request, this puts the requesting process on a queue.
The requesting process remain on a queue until the coordinator receives a release message from
a process in the critical section. Once a release message is received by the coordinator, the
process exits the critical section and a grant message is sent to the requesting process
(Krzyzanowski 2017).

8
7.0 References

DeMent, Naomi S., and Pradip K. Srimani. 1994. ‘A New Algorithm for k Mutual Exclusions
in Distributed Systems’. Journal of Systems and Software 26(2):179–91. doi:
10.1016/0164-1212(94)90087-6.

Derhab, Abdelouahid, and N. Badache. 2008. ‘A Distributed Mutual Exclusion Algorithm over
Multi-Routing Protocol for Mobile’. IJPEDS 23:197–218. doi:
10.1080/17445760701536084.

Florea, Ion, and Corina Nanau. 2015. ‘A Simulation Algorithm for a Single Server Retrial
Queuing System with Batch Arrivals’. Analele Universitatii Ovidius Constanta - Seria
Matematica 23. doi: 10.1515/auom-2015-0007.

Goldman, Kenneth J. 1990. Distributed Algorithm Simulation Using Input/Output Automata:

Fort Belvoir, VA: Defense Technical Information Center. doi: 10.21236/ADA228113.

Huang, Kai. n.d. ‘PYDISTSIM - DISTRIBUTED SYSTEM SIMULATION LIBRARY

USING SIMPY’.

Krzyzanowski, Paul. 2017. ‘Process Synchroniztion’.

Lee, Insup. 2007. ‘CIS 505: Software Systems Lecture Note on Synchronization’.

Patil, Jijnasa, and Radhika Naik. 2014. ‘Comparative Study of Mutual Exclusion Algorithms
in Distributed Systems’. 4(6).

Dr. Rutuja Kadam. 2023. Central Server Algorithm to Implement Distributed Shared Memory.

Aspnes, James. 2022. ‘Notes on Theory of Distributed Systems’.

De Turck, Filip. 2022. ‘Methodology for Simulation-Based Comparison of Algorithms for

Distributed Mutual Exclusion’.

P.J. Eby. 2010. ‘PEP 3333 – Python Web Server Gateway Interface v1.0.1 | Peps.Python.Org’.
Retrieved 3 April 2023 (https://peps.python.org/pep -3333/).

Stumm, Michael, and Songnian Zhou. 1990. ‘Algorithms Implementing Distributed Shared
Memory’. Computer 23:54–64. doi: 10.1109/2.53355.

Thiare, Ousmane, and Papa Alioune Fall. 2012. ‘Using Maekawa’s Algorithm to Perform
Distributed Mutual Exclusion in Quorums’. Advances in Computing 2(4):54–59.

Wismüller, Roland. 2022. ‘Distributed Systems’. Verteilte Systeme.