CSE 5306 Operating Systems-II Summer 2003
Project#1

“Two Phase Commit Protocol”

In this Project, you will simulate a simple Distributed Two Phase Commit Protocol using Multithreading and Sockets in Java. (Note: In project 2, you will do the same algorithm using the higher-level language constructs of JAVA IDL; you can share parts of your code, such as the GUI, between the two projects. The main difference will be in the communication between the processes, so make sure that the communication code is well structured and isolated from the rest of your source code).

Motivation

Many distributed algorithms employ a coordinator process that performs functions needed by the other processes in the system. The two-phase commit protocol employs a coordinator process, plus several local processes. The coordinator needs to ensure that either all local transactions that are part of a global transaction succeed and commit or none of them do.

Project Specifications

The Distributed Environment will have a number of identical local processesplus one coordinator process. All local processes are similar with no distinguishing characteristics. Each process (local or coordinator) has a unique identifier (machine address and port number) and each process knows of every other process (but does not know which is up and which is down). For our project, you will implement a number of additional processes to control and monitor the distributed environment. These include a control server and a display server with a GUI. These processes are mainly used for simulation and monitoring and would generally not exist in a real distributed system. For ease of notation, we will call the coordinator Pc and the other local processes Pi, where i= 1, 2, 3, 4.

Follow the specifications outlined below:

  1. The process Pi running on a remote machine, listens to a designated port. As soon as it is started it first registers itself to the Control Server (Eagle) by specifying its location. Whenever it receives a message, it starts a thread to process that message based on the type of command in the message. A process Pi can receive the following types of messages:

(a)Start_Simulation(process_list) from Eagle.

(b)Crash_Process (from Eagle).

(c)Restart_Process (from Eagle).

(d)Kill_Process (from Eagle via Display).

(e)Start_Subtransaction(T) (from coordinator).

(f)Vote_Request(T) (from coordinator).

(g)Global_Abort(T) (from coordinator).

(h)Global_Commit(T) (from coordinator).

(i)Decision_Request(T) (from another Pi).

(j)Decision_Inform(T, D) (from another Pi; D is either C (commit) or A (abort)).

  1. The coordinator process Pc is running on a remote machine, listens to a designated port. As soon as it is started it first registers itself to the Control Server (Eagle) by specifying its location. Whenever it receives a message, it starts a thread to process that message based on the type of command in the message. Pc can receive the following types of messages:

(a)Start_Simulation(process_list) from Eagle.

(b)Crash_Process (from Eagle).

(c)Restart_Process (from Eagle).

(d)Kill_Process (from Eagle via Display).

(e)Vote_Commit(T) (from any Pi).

(f)Vote_Abort(T) (from any Pi).

  1. The Control Server (we’ll call it Eagle for simplicity) is mainly used for simulation purposes:

(a)It accepts the incoming requests from the Processes (to register their name and location) and maintains this information in a list (Process list).

(b)It accepts the incoming request from the Display Server (to register its location).

(c)It starts the simulation after receiving the registration of Display, Pc, and all Pi’s (i=1,2,3,4).

(d)It also serves other simulation purposes (example: Killing a process).

  1. The Display Server serves the purpose of a monitor and logbook for the distributed system. Each Process will send its status to this Server, which in turn will display the status against the Process ID in a GUI. The user (yourself) will also enter commands to the system through the Display Server.
  2. The Control Server (Eagle) should do the following:

(a)Wait until it receives all registration messages from Pc and the Pi’s and Display.

(b)Send Start_Simulation(process_list) messages to Pc, each Pi, and Display.

(c)Wait 15 seconds, then send a Crash_Process message to Pc or one of the Pi’s; choose the Pc or one of the Pi at random with equal probability (20% probability for each).

(d)Wait 5 seconds, then send a Restart _process message to the same Pc or Pi.

(e)Repeat (c) and (d) until it receives a Kill_simulation message from Display, upon which it sends Kill_Process() to each Pi, then terminates.

  1. Each process Pi should follow these simulation steps (also see textbook p.398):

(1) Create a Process, register it with Eagle, and wait for the Start_Simulation(process_list) from

Eagle.

After the process is started:

(2) Wait for a message Start_Subtransaction(T) (from coordinator).Once it receives such a

message, it waits for a Vote_Request(T) from coordinator.

(3) It then contacts the coordinator by sending Vote_Commit(T) (with 0.9 probability).

or Vote_Abort(T) (with 0.1 probability).

(4) If it had sent a Vote_Commit(T), it waits for either Global_Commit(T) or

Global_Abort(T) from coordinator and takes the appropriate action. If it receives neither within

10 second timeout, it sends Decision_Request(T) to all the other Pi processes and waits for reply.

Each process Pi should continue listening to commands from the coordinator until it receives a message from Eagle. If it receives Crash_Process(), it simply waits for the next message from Eagle and does not accept any messages from the coordinator or other processes. If it receives Restart_Process(), it again listens to messages from the coordinator and other processes. It if receives Kill_Process(), it terminates itself.

  1. The coordinator process Pc should follow these simulation steps (also see textbook p.396):

(1) Create a Process, register it with Eagle, and wait for the Start_Simulation(process_list) from

Eagle

After the process is started:

(2) Waits for for a random time between 0 and 5 secs (based on uniform distribution), then sends

Start_Subtransaction(T) to each Pi (T is a unique integer transaction id, 1, 2, 3, …). It then waits

for another random time between 0 and 5 secs (based on uniform distribution), then sends

Vote_Request(T) to each Pi. (This cycle is repeated by one of the coordinator threads indefinitely

while it is running.)

(3) After sending Vote_Request(T), a coordinator thread waits for a 5 second timeout period to

receive votes on T from the all the Pi processes. If it receives Vote_Commit(T) from all, it sends

Global_Commit(T) to all. If it receives at least one Vote_Abort(T) or passes its timeout period, it

sends Global_Abort(T) to all.

Input/Output Guidelines

  1. Port Addresses should be over 1024, because lower port numbers are used by the OS and Systems programs.
  2. The GUI can be implemented by a Frame or Applet. It may have Labels, TextArea, TextField, and Buttons. You can use a GUI building Tool such as Jbuilder, Jdeveloper, Visual Café, and Symantec Café.
  3. Eagle should be implemented on the Gamma Machine because it supports GUI.

It should be started like this,

> java Eagle eagle’s_port#

Example: > java Eagle gamma.uta.edu 6225

  1. Processes can reside on either Omega or Gamma. Each process Pi should be started like this,

> java Process Pi Pi_port# eagle’s_machine_name eagle’s_port#

Example: > java Process P4 5175 gamma.uta.edu 6225

  1. Display should be implemented on the Gamma Machine.

It should be started like this,

> java Display Display_port# eagle’s_machine_name eagle’s_port#

Example: > java Display 7265 gamma.uta.edu 6225

References

  1. “Distributed Systems: Principles and Paradigms”, Andrew S. Tanenbaum & Maarten van Steen, 2002, Prentice-Hall Inc., ISBN 0130888931, pages 262 – 265.
  2. “Distributed Systems: Concepts and Design”, Coulouris, Dollimore, & Kindberg, 2000, Addison-Wesley, ISBN 0201619180.
  3. “Core Java 2” Volume 1, Cay Horstmann & Gary Cornell, 2000, The Sun Microsystems Press.
  4. “The Java Tutorial”, Sun Microsystems,

Submission

Send mail to Mr.Fu, with questions regarding this project. Your Final Project should contain these files: Process.java, Eagle.java and Display.java. Make a README file, with an explanation of how to compile and run your programs. Put all these files in a directory and compress it using tar and gzip. Send the resulting file (dir.tar.gz) to by midnight on Thursday, July 17 (firm deadline).

General Notes

  1. You can complete this project individually or in a team. If you form a team, it cannot exceed 2 members.
  2. This project will constitute 25% of your overall Grade.
  3. There will be 10% penalty per day late submission. No assignment will be accepted if late more than 3 days.
  4. The code should be easy to understand, handle boundary and error conditions, and be well documented.
  5. You should not steal code from the Web nor should you borrow any code written by fellow students in this class. That would be considered as Cheating.