A Distributed Mutual Exclusion Primitive.

1. Description:
You are asked to develop a distributed mutual exclusion primitive for a number of processes
running on the computers on a single switched LAN (our Linux lab).
System Architecture:
Process1 Process2 Process3 Process4 ...
| | | |
| | | |
| LAN | | |
|------------------|--------------|---------------|-----

The client and servers are running Network File System (NFS) so that user files are visible at
$HOME directory. You may want to set up the following environment:
• $HOME/process.hosts: a list of computers (hostnames) which are running processes that
need the distributed mutual exclusion. There is no reason why your implementation
cannot support up to 5 servers.
Your implementation must follow the distributed mutual exclusion algorithm descrbied below.
• A process sends a REQUEST message to all other processes to request their permission
to enter the critical section. A process sends a REPLY message to a process to give its
permission to that process.
• Processes use vector logical clocks to assign a timestamp to critical section requests and
timestamps are used to decide the priority of requests.
• If the priority cannot be determined by two timestamps (e.g., two concurrent requests),
the process pid will be used as a tie break.
• Each process pi maintains the Request-Deferred array, RDi , the size of which is the
same as the number of processes in the system.
• Initially, ∀i ∀j: RDi[j]=0. Whenever pi defer the request sent by pj , it sets RDi[j]=1 and after
it has sent a REPLY message to pj , it sets RDi[j]=0.
Requesting the critical section (CS):
(a) When a site S i wants to enter the CS, it broadcasts a timestamped REQUEST message to all
other sites.
(b) When site S j receives a REQUEST message from site S i , it sends a REPLY message to site
S i if site S j is neither requesting nor executing the CS, or if the site S j is requesting and S i ’s
request’s timestamp is smaller than site S j’s own request’s timestamp (or pid of S i is smaller if
two timestamps are concurrent). Otherwise, the reply is deferred and S j sets RD j [i]=1.
Executing the critical section:
(c) Site S i enters the CS after it has received a REPLY message from every site it sent a
REQUEST message to.
Releasing the critical section:
(d) When site S i exits the CS, it sends all the deferred REPLY messages: ∀j if RD i [j]=1, then
send a REPLY message to S j and set RD i [j]=0.
Notes:
• When a site receives a message, it must update its clock using the local vector
timestamp and the timestamp carried in the message.
• When a site takes up a request for the CS for processing, it updates its local clock and
assigns a timestamp to the request.
Test:
To demonstrate your distributed mutual exclusion primitive is working, you must provide a test
program (a sample bank code will be provided at a later time) that is running at all computers
listed in your process.hosts file. In the test, you may want to simulate a bank account balance
inquiry, deposit, and withdraw operations from all computers (processes). The application
 program must invoke the distributed mutual exclusion primitive before and after the actually bank
account read/write operations.
Implementation Guidance:
1. Message Structure:
struct msg_packet {
unsigned short cmd; // command, e.g., HELLO | HELLO_ACK | REQUEST | REPLY | IN_CS
(HELLO & HELLO_ACK are additional command for debugging purposes)
unsigned short seq; // sequence number of avoid duplicates
unsigned int hostid; // this is optional because you can obtain the host (sender) information from
the ip header, we add this fied for the convenience.
unsigned int tiebreak; // process's pid goes here for the purpose of a tiebreak
unsigned short vector_time[5]; // support upto to 5 hosts
};
2. process.hosts:
You may artificially give an ID to each host. For example:
turing11.eecs.csuohio.edu 0
turing12.eecs.csuohio.edu 1
turing13.eecs.csuohio.edu 2
turing14.eecs.csuohio.edu 3
turing15.eecs.csuohio.edu 4
Therefore, the timestamps will be in the same order for each host. The host ID (as the index) is
also useful for managing the deferred array.
3. Blocking:
When a process sends a request but does not receive all replies, this process will be blocked until
it receive all the replies.
When you use the UDP platform, this blocking is automatically done for you when you invoke
recvfrom function. Note, you need to maintain a counter that counts how many REPLY
messages you receive from all other hosts. If not enough REPLY received, you still need to call
recvfrom function (and therefore the process is blocked).
2.
3. Requirements:
1. You can only use C programming lanuage to complete this project. Your
implementation should not rely on any extra library (to compile your code) in addition to
the provided UDP example code. Your code must compile by using gcc installed on the
Linux workstations in FH 133. NOTE: you are not allowed to use sleep() function and its
variation.
2. Your distributed mutual exclusion primitive must be based on UDP based socket
programming.
3. (25 points) A UDP networking platform: given the provided UDP example code, your job
is to construct a UDP communication platform for 5 hosts.
4. The UDP base code is provided
5. udp_example.tgz

Your implement must be built on the provide UDP platform and perform a message
communication test as described in the following:
Suppose you have 5 server with their IDs: 0, 1, 2, 3, 4 (contained in $HOME/process.hosts).
•
o Servers with IDs 1, 2, 3, and 4 should be running first and doing nothing
(listening);
o Server 0 runs next. Server 0 sends a "Hello" message (can be emulated by
4 unicasts) to all other servers;
o Once a server receives a "Hello" message, it immediately replies the
sender with a unicast message "Reply".
o When servers 1, 2, 3, and 4 receive a "Hello" from server 0, they wait for a
certain amount of time and then each of them sends a "Hello" to everyone
 else. The waiting time is arranged as the following: server1: 2s; server2:
3s; server3: 5s; server4:7s.
o The response to the "Hello" messages from server 1, 2, 3, & 4, should be
the same way responding the "Hello" from server 0.
o Each server prints out the messages it receives with the following format:
the sender ID: the message content
4. (60 points) Your distributed mutual exclusion primitive must provide a clean interface
(API) such that application programmers only need to invoke the lock and unlock calls
before and after the program enters the critical section. While the lock is not available, the
calling process must be suspended and be waiting for the availability of the lock. Busy
waiting is not allowed.

DIstributed Mutual Exclusion API:

•
o 1. int distributed_mutex_init();
▪ for initialization, should be called by the user who wants to use the
distributed_mutex primitive;
▪ in addition to variable initialization, init() should create a pthread
that is listening on port 0x3333 (for incoming message)
▪ return an int: 0 indicates normal and ready; -1 indicates an error.
o 2. int distributed_mutex_lock();
▪ before the calling user enters in the critical section, the user must
obtain this lock. Or the user should be blocked (waiting)
▪ return an int: 0 indicates normal; -1 indicates an error.
o 3. int distributed_mutex_unlock();
▪ it's the user's responsibility to call unlock before leaving the critical
section. this API should send queued (deferred) REPLY messages
to the sending hosts according the procotol described above.
▪ return in int: 0 indicates normal; -1 indicates an error.
5. (5 points): you will earn up to 5 points if you ask QUALITY questions regarding the
distributed mutual exclusion system design (either email or in-person) while implementing
the project.
6. (10 points) README/Makefile: you are required to write a README document (in txt
format) that describes your project design detail and the execution sequence (with the
commands). In particular, please explicitly state which part, if there is any, does not work
and the possible reasons why that module does not work. For those working modules,
please give a brief (in short) sample output. You are also required to provide a working
Makefile that compiles your code (with the cleanning option).
*********************** Further Hint: Server Process Implementation Details.
************************************
Note that two or more processes may send the requests simultaneously. To respond the
requests instantaneouly and timely, each server process should process the requests
concurrently. That is, for each received request, a new thread (using Linux pthread
library) should be spawned to service this request.
The duty of the spawned thread is to process the incoming message. It's duty includes,
but not litmited to, in the following:
1. If the host receives a REQUEST message and the host is not requesting, sends a REPLY
immediately;
2. If the host receives a REQUEST message and the host is also requesting:
a) the host has a vector time earlier than that of REQUEST (or a smaller pid if two
timestamps are concurrent), defer the REPLY and put the REQUEST in the queue;
b) the host has a vector time later than that of REQUEST (or a larger pid if two
timestamps are concurrent), sends a REPLY immediately.
3. If the host receives an other message, e.g., HELLO, replies an ACK immediately.
The communication between the spawned thread and the main thread
(distributed_mutex_lock()) can be done through pthread semaphore, including the
following three api functions:
sem_init(), sem_wait(), and sem_post().