CS 342 Lab 8: Distributed Server
Use your sort program from Lab 7 to implement a distributed
sort. Measure the performance of your sorter, both on a single
machine and distributed.
NOTE: you can work either alone, or in groups of two or three
(maximum!) students for this lab. If working
in a group, the group submits only one lab report, which must
show the names of all group members. All group members will
receive the same grade for this lab.
- Review your Lab 7.
- Review the code in tcpserver.cpp
- Measure the performance of your sorter, using the best
sort algorithm that you added in Lab 7.
- Performance, in this case, means the time required
to sort a large data set. You can use the C library functions
::gettimeofday () or
::gethrtime () to measure the time.
NOTE: If working in
a group, you must package your use of the timing functions in
a small timer class. You might provide methods such as
- Use the data set in
(Copy that file to /tmp on your machine and gunzip it.)
- Treat the data as lines of text (character arrays). Therefore,
we won't be able to use the Java Sort_Viewer in Lab 8.
- Please do not use the CEC server machines
(hilton, ritz, clarion) for performance tests. Use the
Sparcstations in the lab, instead. The 360 MHz Sparc 5 should
be adequate, especially after copying the data set to /tmp.
- Implement distributed sort.
- It's best to write a special object that coordinates
distribution of the sort. It partitions the original input
data, sends individual partitions to remote machines for sorting,
collects the responses, and merges them to form the sorted result.
- You'll need to write an acceptor, to receive requests
over a socket from another machine. See the code in
tcpclient.cpp for an example.
- The acceptor can receive the request, perform the local
sort, and send the response back. Be sure to arrange some
way for the response to be sent back. Sockets are bidirectional,
so that part is easy. The tricky part is distributing the
sorts in order to support parallelism. It is worth
investing time to decide how to do this. It can be done without
using multiple threads or processes on one machine!
- Be sure to package your design and code nicely.
NOTE: If working
in a group, you really must develop a conceptually appealing
design and implement cleanly.
- Measure the performance of a distributed sort. If you're working
alone, a single comparison between one machine and a distributed
sort is sufficient. If you're working in a group, your group must
study the tradeoff between number of machines and sort time.
- NOTE: Those working in
groups will have to demonstrate their distributed sorts. (Either
during lab session, or during reading week.)
- Optional: use Command pattern to structure your remote requests.
It's cool, and will probably save time overall if you do it that
way. But, it takes more up-front planning.
Obtaining the Lab 8 distribution:
At a Unix shell prompt, type
~cs342/bin/lab8. That will
copy a Makefile, readme, and the tcpclient/server example code to a
lab8 subdirectory. You can then
and copy your lab7 code.
What to Submit:
By the due date, submit all source files from
your final solution. Include a laboratory writeup file (named
readme) documenting what you did to satisfy this
readme contains a minimum list of sections
that you must provide. (Please replace the comments in  with your
descriptions.) These files will be submitted automatically when you
execute the command:
NOTE: there is a Makefile target that allows you to
test what you are going to turn in:
It places the output that will be
turned in into the
TEST_TURNIN directory. You are
responsible for using
make test_turnin, and verifying
that the files that you will submit are correct.
Please see the Lab 4
assignment for notes on using the History class to help track and
count instantiations and deletions of an instrumented class.
Please see the Lab 2 assignment
for hints on compiling templates.
CS 342 newsgroup