Milestone 4‎ > ‎

Submission instructions

Assignment 4 Test Submit

Testsubmit Assignment 4 as follows.

> /cad2/ece297s/public/testsubmitece297s 4

Please note that the testsubmitece297s script tests wether all required files are included, the project is buildable, and the available test cases pass. This script does not submit your code. You may use it as a check before you are ready to submit your code. Once you get the positive confirmation from the testsubmitece297s script (Your code is ready for submission), follow the instructions here to submit your code. We highly recommend that you continue to use the testsubmitece297s script throughout the assignment and not leave it untill the last minute before the deadline. This script is meant to help you understand what works and what tests pass successfully, and what you may want to fix before submitting. Note that we will process additional test cases with your submission, which are not included in the test cases available to you via the submission script. This may mean that while the script tells you to go ahead with your submission, your code may still exhibit bugs and may not pass all the test cases we will be subjecting it to.

Save the output of the Testsubmit script as follows.

> /cad2/ece297s/public/testsubmitece297s 4 > testsubmitAss4.log

Please make sure that you include the output file testsubmitAss4.log in storage-asst4.tgz as your are required to submit it as part of your code.

Code submission instructions

Follow these instructions to submit your code and performance report. Only one member of each team should submit the code.

Make sure the FINAL versions of all your changes are added and committed to the Subversion repository. ''Don't forget to svn add and svn commit any new files (other than binary files) you created.''

You will be submitting three files: storage-asst4.tgz will contain your complete source code, storage-asst4.diff will contain a record of the changes you've made to the code since the initial checkin, and performance-asst4.pdf is a PDF version of your performance analysis document.

  • Create and submit storage-asst4.tgz as follows.
    > mkdir ~/ece297/submit
    > svn export ~/ece297/storage ~/ece297/submit/storage-asst4
    > cd ~/ece297/submit
    > tar zcf storage-asst4.tgz storage-asst4
    > rm -r storage-asst4
    > /local/bin/submitece297s 4 storage-asst4.tgz

Refer to this page for a list of common submission problems and how to solve them.

  • Create and submit storage-asst4.diff as follows.
    > mkdir ~/ece297/submit
    > cd ~/ece297/storage
    > svn diff -r 1:HEAD > ~/ece297/submit/storage-asst4.diff
    > cd ~/ece297/submit
    > /local/bin/submitece297s 4 storage-asst4.diff
  • Submit performance-asst4.pdf as follows (assuming the PDF file is in the ~/ece297/submit directory).
    > cd ~/ece297/submit
    > /local/bin/submitece297s 4 performance-asst4.pdf

You can see what files you have submitted by entering:

> /local/bin/submitece297s -l 4

In particular check the file size and date to confirm the correct file was submitted.

Carefully examine the .tgz and .diff files to make sure all your changes are there, including any unit tests you wrote.

Check Submitted Files

We only mark the most recent files submitted by any member of the teams. You can see which submitted files will be marked by entering below line at all team members' command prompt:

> checksubmit 4

In particular check the file size and latest submission date to confirm the correct file was submitted. Carefully examine the .tgz and .diff files to make sure all your changes are there, including the unit tests you added.

Common Submission Problems

Refer to the page here for some common submission problems and how to solve them.

Marking guidelines

Your assignment will be marked based on the code you submit, the performance evaluation report, and the design document.

The code you submit for this assignment will be evaluated as follows. We will build your system and test it for correctness based on a set of test cases. Similar tests from the previous milestone will be used, but with different combination of concurrency.

It is critically important that you adhere to the Makefile template and code template we provide for you, as our build scripts will be based on these files. At the very least make sure the test suites given to you pass.

Marks will also be allocated to the number of test cases your system correctly passes.

As with Assignment 1, the fundamental basis of evaluation for the design document are principles laid out in the course text book. That is, we will not be grading on the basis of qualitative judgments of what makes good or bad writing, but rather how well you are able to implement awareness of purpose and audience, overall organization, rhetorical tools, paragraph and sentence level clarity, as well as visual elements.

You are expected to be able to analyze the instructions in order to determine the design decisions pertinent to the assignment and to discuss these decisions in an orderly fashion. Information must be easy to find and choices must be made in relation to measurable qualities. Language must be precise, efficient and correct.

Over the course of the term, you are expected to develop and document a design methodology; in this assignment and previous ones, you are expected to exhibit a clear, systematic method of expressing design decisions.

Tentative code marking scheme

Here is the marking scheme for the coding portion:

  • [4 marks] Build+Submission: 2 marks if the server and client library build without error, or 1 mark if they build after a reasonable effort to fix submission problems. Plus 1 marks if the submission is a valid SVN export, and 1 marks for submitting a .diff file.
  • [2 marks] Coding attempt: 1 marks for implementing support for concurrency and 1 marks for implementing support for transactions.
  • [98 marks] Marking tests: 1 mark for each test passed by the automarker. The automarker will evaluate a range of operations and features provided by your storage server up to this milestone.
  • [3 marks] Technical correctness of your performance evaluation report.

In addition up to 24 bonus marks allocations:

  • Bonus for implementing and evaluating a second concurrency mechanism.
  • Bonus for implementing and evaluating a third concurrency mechanism.

Some of the marking tests are available at /cad2/ece297s/public/assignment4/a4-partial.tgz.

You can try running them as follows.

> cd ~/ece297/storage/test
> tar zxf /cad2/ece297s/public/assignment4/a4-partial.tgz
> cd a4-partial
> make clean run

Note that by default the config files used by the tests enable concurrency method 1. To test with different concurrency policies, edit the *.conf files accordingly.

Some notes and synchronization hints

We suggest that you follow the below items carefully in order to avoid some of the most common synchronization issues

  • If using threads, note that generate_encrypted_password() is not a thread-safe function. This function is defined in utils.c and uses crypt(), a standard unix utility function. The encrypted value returned by crypt() is overwritten after each call, meaning that if you call this function twice, both return values will be the same. To avoid problems, consider acquiring a lock prior to callinggenerate_encrypted_password() and also compare its returned value against the value of server_enc_passwd prior to releasing it. Alternatively, you can call generate_encrypted_password() on the client-side and send the result to the server. Since the client has one thread, you should not experience an issue.
  • Make sure that each client connection is authenticated separately, and failure or success of authentication process of one client does not impact others.
  • For concurrency using threads, do not forget to add -lpthread as a linker flag to your makefile. This is needed to successfully compile your threaded code on ug machines.
  • If you have not implemented non-mandatory concurrency modes (i.e., optional bonus parts of the assignment), your server must exit right after parsing the config file. You will face some penalty if the server simply runs the default concurrency (i.e., concurrency is set to 1) even when concurrency is set to 2 or 3.

Bonus marks

In this assignment you may obtain the following bonus marks.

  • If your Assignment 4 submission builds successfully and passes 80% of the test cases we apply, the coding portion of your Assignment 3 mark will be increased to 60%. If your Assignment 3 coding mark was already more than 60%, your mark will not be changed.
  • Bonus marks if you implement and evaluate a second method to support multiple connections and concurrent request processing in your server.
  • Bonus marks if you implement and evaluate a third method to support multiple connections and concurrent request processing in your server.