CS 342 Lab 8: Distributed Server

http://www.cs.wustl.edu/~levine/courses/cs342/lab/lab8/

Lab date: 4 April-27 April 2000
Due date: Friday 28 April 2000 11:59 pm

Objective:

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.

Preparation:

1. Review your Lab 7.

2. Review the code in tcpserver.cpp and tcpclient.cpp.

Assignment:

1. 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 start, stop, and get_time.

   • Use the data set in ~cs342/lab8-data1.txt.gz. (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.

2. 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 tcpserver.cpp and 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.

3. 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.

4. NOTE: Those working in groups will have to demonstrate their distributed sorts. (Either during lab session, or during reading week.)

5. 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:

What to Submit:

make turnin

make test_turnin

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.