Project Overview
For this project you will be implementing pieces for a distributed
computation system that will use Java RMI to communicate with each other.
Getting Started
We've put a number of starter files into your CVS repository.
They are spread out into 5 different packages;
p5common,
p5registry,
p5client,
p5server,
p5test.
Some of these are completed. Others have un-implemented sections
that you need to implement. It is critical that you do not alter
the files in the p5common package.
The pieces of the whole.
p5common: This package contains the prototypes for the
methods that the server object will make available (PrimeProcessor
interface) as well as a serializable utility class (PrimeTuple
for keeping an integer and it's primality value together)
and a class created to make
it easier to tweak details as you test on your machine (Details).
A CRITICAL CHANGE THAT YOU MUST MAKE in the
Details class is used to set the theRegistryPort value to a
five-digit number based on the pattern 33##4
where 33 was taken from the course (433) and ##
NEEDS TO BE the last two digits of your
linuxlab login and 4 represents this project.
There are also variables in there such as shared pair
of values that will be used to set
the start and end of the range of integers to test for primality.
p5registry: This package contains a class we built to run
an RMI registry on your machine listening to the port defined in
Details. This isn't how a general registry would typically be
run but on Windows machines there are issues that make this the easier
solution for us. Do not change this file.
p5client: This package will contain different types of clients
that will communicate via RMI with your server object. Each client will
request some number of integers to work on. "Good" clients will then do
that work and send their answers back to the server. "Bad" clients might
do none of the work or might do only part of the work they were expected
to do. The server will need to deal with this. We have provided an
example of a "bad" client (PrimeTestingBadClient) that you should
not change.
There is also the
starting point of a "good" client (PrimeTestingClientNumber1) that you
need to implement. You will also need to implement a second client called
PrimeTestingClientNumber2 (after you
implement and test PrimeTestingClientNumber1) which works slightly
differently (details in the comments).
Secret testing will also use clients of our own that follow the same
RMI rules that we place into this package for our own testing of your
project, though our client could (for example) ask for 50 numbers to
check but then only return information about some of them.
p5server: This package contains PrimeTaskServer
which implements PrimeProcessor. You need to implement the
methods made available via RMI (requestListToProcess and
submitListOfResults). The comments explain the names and
access levels of two required fields - you need to choose appropriate
types of lists for these to achieve good speed-up when their are
multiple clients talking to the server simultaneously while also
guarding against the dangers of concurrency. You may add additional
fields or private methods if needed. The server needs to handle
the scenario where clients ask for different sized lists to process
and also for the scenario where a client only returns some of the
answers (they will not return incorrect answers).
p5test: This package contains some example JUnit tests
that will run the entire system on a single machine. These test a
few specific scenarios of how the server object might interact
with client(s). Note that the tests look directly at the unknown
and known lists inside the PrimeTaskServer object - this
is just to make testing for us a little easier.
Running the whole system.
For the sake of simplicity, you will be able to run all of the elements
on a single machine talking to itself. However, in theory, the clients
would all be running on hosts other than the one that the registry and
the server are.
Grading
Grading will mostly be hand-grading for this project. The majority
of the points will be associated with having a working distributed
system. Your server will need to be able to handle clients that
don't always give answers to all the questions they were asked (so you
might want to think about how to test for that). There will also be
a large portion of the grading associated with speed-up
when there are multiple clients simultaneously requesting and
processing tasks. This problem is very amenable to speed-up (where
with 3 clients on a four-processor machine you could actually get
close to a 3x speed-up).
Testing
You should test your project with all of the example tests and
try others you come up with as well. We will have two tests on
the submit server so you can check that things will compile and
run when we do hand-grading on your project.
What to Turn In
Every file you submit should have your name and UID. To enforce
academic integrity, code will be checked for similarity to other
submissions. Each student should make his or her own individual
submission.
Use Eclipse to submit your project.
You are also required to submit a short "design discussion"
inside a text file names DesignDiscussion.txt in your project folder.
This should describe the design choices you made in implementing
the server object methods in this project.
|