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.
 

• On or before October 24, you will submit (electronically) a document which provides preliminary systemspecs and design, assumptions you have made, and a plan of execution (including a proposed timeline). This should be emailed to cmsc621@cs.umbc.edu with the subject  "First Project Report".
• On November 21, you will submit a brief  report of your progress to date, changes in the design if any, as well as an updated timeline. Again, this will be via email , with the subject "Second Project Report".
• The project report detailing your work (the system design, experimental studies etc.) as well as submission of your code, will due on December 12, 2000 in a similar manner - emailed with subject as "Final Report". Code should be attached as a tarred, gzipped file. Please note that pdf, ps and text (formatted to 72 columns) are the only formats we will accept.
• You will also arrange to demonstrate your project to the instructor between December 6 and December 13. The report and code submission must precede the demonstration by 24 hours.

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.

• Jini
• Service Location Protocol
• UPnP
• Salutation