Programming Assignments - CSCI 353, Spring 2018

All programming assignments are individual assignments. Although you are encouraged to "work with" your classmates at a "high level". When it's time to write code, make sure you write your code privately. Technically speaking, "sharing" a single line of code or pseudo-code with your classmates is considered cheating. If you don't know how to work with another person and not end up "sharing/copying" code, you are advised not to work together with your classmates at all in programming assignments.

Warmup Assignment:

• Programming Assignment 1 (PA1: graph algorithms in C/C++), due 11:45PM, 1/26/2018. Electronic submissions only.

Networking Assignments: (It's not a typo that PA2 and PA3 have the same due date.)

• Programming Assignment 2 (PA2: simple web server in C/C++), due 11:45PM, 2/9/2018. Electronic submissions only.
• Programming Assignment 3 (PA3: simple web client in C/C++), due 11:45PM, 2/9/2018. Electronic submissions only.
• Programming Assignment 4 (PA4: multithreaded traffic throttling web server in C/C++), due 11:45PM, 3/2/2018. Electronic submissions only.
• Programming Assignment 5 (PA5: network of servers in C/C++, part 1 - network formation), due 11:45PM, 4/20/2018 (extended). Electronic submissions only.
  [BC: updated 3/27/2018]
  Extra credit for early submission is now a bit involved for PA5.
  If you submit PA5 before 11:45PM on 4/3/2018, you get 30% extra credit.
  If you submit PA5 before 11:45PM on 4/4/2018, you get 25% extra credit.
  If you submit PA5 before 11:45PM on 4/6/2018, you get 20% extra credit.
  If you submit PA5 before 11:45PM on 4/13/2018, you get 15% extra credit.
  If you submit PA5 before 11:45PM on 4/17/2018, you get 10% extra credit.
  If you submit PA5 before 11:45PM on 4/18/2018, you get 5% extra credit.
• Programming Assignment 6 (PA6: network of servers in C/C++, part 2 - network application), due 11:45PM, 4/20/2018. Electronic submissions only.
  [BC: updated 3/27/2018]
  PA6 is now an extra credit assignment. Please note that you are eligible to receive extra credit for PA6 only if you submit PA5 before 11:45PM on 4/13/2018.

PA1:		7%
PA2:		16%
PA3:		7%
PA4:		20%
PA5:		40%
PA6:		10%	(extra credit)

All programming assignments must compile and run on nunki.usc.edu (which runs the Solaris OS) in the grading account (to which you do not have access) or on a Ubuntu 14.04 or 16.04 machine running inside VMware/VirtualBox/VagrantBox. It is your responsibilities to make sure that your code can run in ANY account on nunki.usc.edu or on a Ubuntu 14.04 or 16.04 machine running inside VMware/VirtualBox/VagrantBox. How can you make sure of that?! Well, you need to know what every line of your code is doing, then you can be sure. The key is to make sure that your code does not use any files from you account on nunki.usc.edu or anything that's only available on your Ubuntu 14.04 or 16.04 system. If you ask any of the teaching staff to run your code in the grading account on nunki.usc.edu before grading commence or on a Ubuntu 14.04 or 16.04 machine running inside VMware/VirtualBox/VagrantBox, the teaching staff will refuse to help you with that.

You must NOT use github.com because if you don't pay them within a certain time frame, your private repository will automatically become public! Once your code becomes public, future students will be able to copy your code and you will end up helping them to cheat! USC Student Conduct Code (which you have agreed to when you became a student at USC) says that you must not cheat off other students AND you must not knowingly allow other students to cheat off of you. By allowing your code to apper in public, which will perit future students to have access to your code, you are violating the USC Student Conduct Code!

For the above reason, please do not use github.com as your "online resume" to host your code. If you do that, you will be knowingly violating USC Student Conduct Code.

BitBucket is like github.com in that it combines version control and backup. The main difference is that private projects on bitbucket.com stays private.

1. Create an academic account on BitBucket. You must use your USC e-mail address.

2. You must make sure to make your git repository private. When you create a new repository, by default, the repository would be private. So, don't change that! If for some reason it's showing "public", select "private" before you create the repository). Failing to do so would be considered cheating (since you are allowing other students to cheat from you) and can lead to very serious consequences. If you cannot make your git repository private, you should NOT use BitBucket!

3. For a repository, you can change its settings and you can make the repository public. Please don't do that! If a prospective employer asks you to do that, you must tell them that you are not allowed to do that because you have agreed to the USC student conduct code when you were a student at USC and the USC student conduct code says that you must not cheat off other students and you must not knowingly allow other students to cheat off of you. You can e-mail them a private copy of your code and you must not include anything you do not have rights to distribute.

Once you have created a repository, say, "pa1", you can do the following on your laptop in a terminal:

1. Change directory (using the "cd" command) to your "pa1" directory then do the following only once:

       git init
       git remote add origin https://YOURACCOUNTNAME@bitbucket.org/billcheng/pa1.git

2. Add files to the repository. For example:

       git add *.c *.h Makefile *README.txt
       git commit -m 'Initial commit'
       git push -u origin master --tags

3. After you have made changes to some of the files, you can do the following to update the repository:

       git commit -a
       git push origin master --tags

   You should do the above at least once a day so that what's on your laptop do not get too much out of sync with the repository.

The above are just some examples to get you started quickly. To learn more about "git", please please read the free online book, Pro Git, mentioned in the textbooks section of our course description web page.

1. The class programming assignments will be C/C++ code to be developed on a UNIX environment. No other programming language will be accepted and your program must compile and run with a Makefile as is. You must be familiar with the UNIX development environment (vi/pico/emacs, cc/gcc, make, etc.) Please read the general programming FAQ if you need a refresher on C file I/O and bit/byte manipulications.

2. For any programming assignment, you should use your USC accounts and preferably work on the Solaris machines via ssh for testing. The final (submitted) program must run on nunki.usc.edu because we are going to test it in that environment. (Please note that since Lecture 1, I have announced that there are other options.) If your program is suppose to run on a Ubuntu 14.04 or 16.04 machine running inside VMware/VirtualBox/VagrantBox, we have to use the grader's machine with a similar setup to grade your submission and you will not have access to the grader's machine. Please note that we can only grade your submission from the grading account on nunki.usc.edu or on the grader's Ubuntu 14.04 or 16.04 machine running inside VMware/VirtualBox/VagrantBox. It would be a good idea to test your program in another student's account to make sure that it runs everywhere. By the way, you should not do the whole program development on nunki.usc.edu, as nunki is a general purpose server - under heavy use by many students. But you should definitely test your program there. Please also note that regrades can only be done from the grading account on nunki.usc.edu or on the grader's Ubuntu 14.04 or 16.04 machine running inside VMware/VirtualBox/VagrantBox.

3. For any programming assignment, please do not hardcode any directory path in your code! If you hardcode something like "/home/scf-..." or "/auto/home/scf-..." in your code to access something in your home directory and the grader cannot access these directories during grading, we will not be able to make changes to the overall filesystem on nunki. You may only get a score of 1 point as a result of this. So, please make sure you are not doing this. Please understand that this is your responsibility. All path should be specified externally, as far as your code is concerned.

   The only path that you can hardcode is probably "/tmp", and even that is not a great idea. What you can do is to define such a path as a compile time variable and pass it to your program. For example, you can use the following to define TMPDIR to be equal to "/tmp":

       gcc ... -DTMPDIR=\"/tmp\" ...

   Then in your code, you can do:

       char tmpfile[256];
   
       snprintf(tmpfile, sizeof(tmpfile), "%s/XXXXXX", TMPDIR);
       ... mkstemp(tmpfile) ...

   Basically, using a compile time variable is the same as doing the following in your code:

       #define TMPDIR "/tmp"

   The difference is that you are doing it outside of your code, and this is cleaner.

   By the way, Unix file system path can be as long as 256 bytes. So, if you have a char-array variable that will hold a file system path, make sure it's at least 256 bytes in size.

4. We will make grading guidelines available at least one week before an assignment is due. We will grade based on the grading guidelines (may be with minor adjustments). Since you know exactly how we are going to grade, grading will be harsh. The general rule is that you do not get credit for simply coding. You only get credit for getting your code to work correctly according to the spec and produce the correct output. (Please do not ask the grader to look at your code so you can get more points because you have done a lot of coding and your code looks like it should work. If your code is close to working correctly, it's your responsiblity to get your code to work correctly and produce the correct output.)

   Please understand that all the requirements mentioned in the spec and grading guidelines are serious requirements for all programming assignments. If you have a minor bug that causes a lot of tests to fail, you may end up losing a lot of points. (Therefore, for starters, don't name your executable to be anything other than the one mentioned in the spec and grading guidelines.) For the same mistake in your code, you may get points deducted over and over again (i.e., do expect "double jeopardy", "triple jeopardy", etc.).

5. Early submissions may get you extra credit, if you submit more than 48 hours before the submission deadline. Please see the extra credit policy.

6. Late submissions will receive severe penalties. Please see the late policy.

7. All submissions will be timestamped by the submission server and receipts (known as tickets) will be issued. Whether your submission arrived to the server by the deadline is determined by the timestamp. Please do not delete your receipts/tickets from your home directory on nunki.usc.edu.

8. If you sign up late for this class, you are still required to turn in all the programming assignments on time or you will receive a score of zero for the applicable assignments. No exceptions! This requirement also applys to students on the wait list.

9. You must follow the Electronic Submission Guidelines when you submit programming assignments. Please note that this is a fairly new procedure and very different from previous procedures. Please make sure you read the output of the bsubmit program carefully. It should look similar to the sample output given on the bsubmit page. The timestamped upload ticket issued by the Bistro server is a proof that the server has received your submission (and you do not need additional proof such as an e-mail confirmation). You should also verify what you have submitted is what you intended to submit by following the Verify Your Submission procedure. Please note that it is your responsibility to ensure that you have submitted valid submissions and that you have received timestampted upload tickets for them. Please understand that a file system timestamp can be easily forged. The only kind of timestamp that we can accept is a timestamp given by a server under my control.

It should be clear that you cannot use code written by other students in a previous semester no matter what. As clearly in spelled out in the academic integrity policy of this class, if you have a copy of any of our programming assignments written by someone else, looking at the code or running the code is considered cheating, let alone copying code from it.

What about code you find online? First of all, it has to be publically available code (suh as stuff you find in stackoverflow.com). If it's a paid site or password protected, then it's not public. Also, you must not compile the code you got online into a library and have your code link to them. If you want to use any code online, you should extract what you need (make sure you understand them perfectly) and add it to your source code and cite where you got the source properly (see below).

What if you end up with the same code fragment as another student because you copy the code fragment from the same place online? This will make it look like you copied/shared code with another student. Well, this is why it's important to cite your the source of your code. The proper way to cite your source is to do it inline in your C/C++ file. Please understand that it's improper to simply give citation in your README file. Here's what your code should look like:

    /* Begin code (derived) from [URL] */
    /* If the code you got requires you to include its copyright information, put copyright here. */
    [ code you copied or derived from above URL ]
    /* End code from [URL] */

You are allowed to use code given to you as part of this class (i.e., from textbook or lectures). You do not need to cite such code.

One line (128 characters max) of change is defined as one of the following:

• Add 1 line before (or after) line x of file y
• Delete line x of file y
• Replace line x of file y by 1 line
• Move line x of file z to before (or after) line y

Afterwards, additional modifications cost 12 points per line until 7 days past the submission deadline. After 7 days past the submission deadline, an additional modification costs 30 points per line.

Please note that this applies to source code, Makefile, and README files. Please understand that the grader is NOT allowed to modify your source code or Makefile during grading.

Just want to be very clear about this... The free 3 lines of changes are only applicable if you submit them within 24 hours of the submission deadline. Also, a "modification" is NOT considered a "new submission". So, sending a "modification request" will not change the timestamp of the submission we grade.

Chances are that you have corrupted memory (or have corrupted the memory allocation chain). Memory corruption means that a memory location got modified in a bad way and you have no idea when it happened or how it happened. It's as if it has gone bad all by itself. But since it really cannot go bad all by itself, it just be your code that somehow corrupted memory! When you notice that memory corruption has occurred, this usually implies that you have corrupted memory a while back. It just happened that when you call malloc() or free(), the corrupted memory caused a bus error or the execution of an illegal instruction. By the way, bus errors and illegal instructions are basically the same thing as segmentation faults. If you see something like "stack smash", it's another form of memory corruption bug (unless you really try to "smash the stack").

How does one corrupt memory (or corrupt the memory allocation chain)? You can write beyond an allocated memory block. You can free the same object twice. You can free an object that was not allocated. You can write to an object that's already freed. You can write to a portion of a stack space that is no longer valid. These bugs are hard to find because most of the them you only see that there is problem long time after you have "corrupted memory". We will talk about all this when we go over "dynamic storage allocation" in Ch 3 of the textbook.

If you have access to a professional/expensive debugging tool, it may be helpful. Otherwise, you just need to do binary search and see where the bug(s) might be. There's no magical cures in debugging memory corruption bugs, not even for professionals! I, unfortunately, do not have any magic tricks that can help anyone find memory corruption bugs.

One thing you might try is to temporarily turn off memory deallocation (if you suspect that you have freed the same object twice or freed an object that was not allocated). You can do the following to define free() as a no-op in a common header file when you are debugging:

    #ifdef DEBUGGING_MEMORY_CORRUPTION
    #ifdef free
    #undef free
    #endif /* free */
    #define free
    #endif /* DEBUGGING_MEMORY_CORRUPTION */

As your code gets more and more complicated, you may get more of these bugs. This is one reason why you want to keep your code nice and clean.

If you develop your code on a Linux machine, you can try valgrind. If you have installed Linux on your laptop/desktop, you should give it a try. Just prefix your commandline by "valgrind" (or "valgrind --tool=exp-sgcheck") and read the output carefully. Figure out why valgrind is complaining and fix EVERYTHING it's complaining about. Although valgrind cannot catch every memory corruption bug, it does a pretty good job. For warmup programs, it's worthwhile to make your code runs on both Linux and Solaris because you can use valgrind to look for bugs on Linux. This way, you won't have to look for all your bugs on Solaris which can be more painful!

If you have installed Linux on your laptop/desktop, just use the following command to install valgrind:

    sudo apt-get install valgrind

If your program is memory-corruption free and you just want to look for memory leaks, you can run your program by prefixing it with "valgrind --leak-check=full" and see what valgrind has found for you.

Recently, I have heard about two more memory debuggers.

• cppcheck - Static analysis of C/C++ code. Checks for: memory leaks, mismatching allocation-deallocation, buffer overrun, and many more. To install on Ubuntu, do

      sudo apt-get install cppcheck

• libefence - Helps you detect two common programming bugs: software that overruns the boundaries of a malloc() memory allocation and software that touches a memory allocation that has been released by free().

      sudo apt-get install electric-fence