The Mechanics
You will do this project in groups. The group shall have no less than three,
and no more than four members. Groups with less than three members will not be
allowed, unless extreme circumstances demand it. In any case, such groups will
still be judged against the same criteria as regular groups.
You are allowed to discuss the project across groups. Clearly, you are
not allowed to share solutions. You may read papers and textbooks in this area
as well -- some pointers are provided in this document. However, you should cite
the sources you have consulted. It is intended that you will do this project
using Java on the CS/UCS Unix systems. However, you are free to chose another
imperative language should you so desire, as long as the project runs on CS/UCS
machines.
The Project ( 100 points)
In this project, you will design a distributed process execution environment.
The system will have several sites. Each site will have processes running. When
a new task arrives, the site will analyse its load and decide whether it can
execute the task. If it decides to execute the task, it will locate the code
(object) corresponding to the task using some discovery method. It will then get
the code and execute it. If the site decides not to execute the new task then it
will have to discover some other site which is willing to execute this task. The
new site should be choosen such that the system is load balanced. The new site
will then locate the task, fetch it and execute it. You may assume that any task
in the system consists of serializable code , and that they all load the system
equally.
Extra Credit - 25 points
In the project, the load balancing is done by always migrating the task that
initiated the load-balancing algorithm.This does not involve freezing the state
of a task and migrating the state to a new site. Implement the system such that
the task to be migrated is choosen from all the tasks running at that site.
Experiments
A part of your project is to design and carry out an experimental validation to convince us that your system works. You should also analyze your system for scalability -- number of hosts, number of tasks, etc. You should experiment with different workload mixtures. Comment on the results you get -- try to identify what assumptions you made or implementation mechanisms of your system cause particular scalability patterns. Try and identify both the strengths and weaknesses of your system. If you use your experimental resultsto refine your design, make sure you bring this out in your report.
Some general suggestions
As should be evident to most of you, it is imperative for a project of this complexity and involving teams that you design your system before you code! In your design, you will need to make assumptions as you flesh in the details of the system. Please make sure that you state them in your design document. Make a timeline for your work, and try and stick to it. Where you divide tasks, make sure you clearly define points of articulation and interfaces between modules. As you form groups, please make sure that you can find a common time to meet. This is especially true for those who are part time students and hold jobs which will restrict your schedule. Please comment your code well -- it will help both you and us. You in figuring out code your partners have written, us in grading it. Also, use some form of revision control on your source tree. CS/UCS machines have systems such as CVS and RCS available for your use. This will help if lightening strikes, UPC fails and machines/disks crash, making your recent changes disappear! Please do create makefiles as well.
References
Distributed Load Balancing algorithms will be covered
in class. You can use any one of those algorithms. You may propose and use your
own algorithm with prior approval of the professor. For Service Discovery, you
may use any of the industry standards specified below, or create one of your
own.