A distributed sort partitions the original Sort_Info into multiple, smaller ones. It sends each small Sort_Info to a remote Sorter, then combines the results using mergesort. Note that we don't actually implement the distribution. We just provide the support for it, through the ability to read Sort_Info from files. And, we provide mergesort, which is appropriate for combining sorted arrays.
Sort_Viewer_Client.ccimplementation by inserting an Adapter between them. The calls to the "raw" connect_to_viewer (), send_to_viewer (), and disconnect_from_viewer () functions work, but they're not clean. The Adapter class will 1) hide the sockfd and stream objects, and 2) make sure that connect_to_viewer () is called before send_to_viewer (), and disconnect_to_viewer () is called when done. That way, the user won't explicitly setup and teardown the connection to the viewer. If you had done this for Lab 6, make sure that your code is very clean, concise, readable, elegant, and documented. (If you had incorporated your adapter into an Observer, separate it out. Then your Observer code should be very simple.)
create_sorterFactory Method to support creation of instances of Merge_Sort and your other Sorter.
It's best if you structure your mergesort just like any other Sorter. Then, add a constructor that takes in an Array of Sort_Infos. Mergesort will then check each Sort_Info in the Array: if they're all SORTED, then it simply merges them together.
Sort_Viewer_Client.ccis robust. The Adapter's constructor should call
connect_to_viewer, and its destructor should call
connect_to_viewerfails, the Adapter can either assert failure, throw an exception (if you use exception handling), or return a failure status through a reference argument.
~cs342/bin/lab7. That will copy a readme and your Lab 6 Makefile to a new
cd lab7and copy your other Lab 6 files.
readme) documenting what you did to satisfy this assignment.
readmecontains 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 6 assignment for notes on using the Java Sort Viewer.
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.