COMS6181 Advanced Internet
Services, Summer 2004
Homework Submission Instructions
Before you submit, please check:
Written Part:
- The written part of the assignment should be submitted
in either plain text or PDF format. For almost all problems, plain text should be sufficient,
with
'drawings' done in ASCII. For packet headers, you can follow the
standard 4-byte-per-row format in RFCs. If you do want to submit text
written in Word or LaTeX, please convert it to PDF. For
LaTeX, dvipdf does this in one step. For Windows tools, you can use one
of the available PDF converters. A cheap one is the one found at
www.pdf995.com. Finally, please include your
Name and Email in your assignment!
Programming Part:
- The application can be written in C(++) or Java. You
may choose either Linux, Solaris or Windows (XP). The programming style
guidelines
apply. You should omit the Columbia copyright, since assignments belong to the
author, not the university.
- Programs submitted will usually be graded in Linux
with common development tools such as gcc and javac. Specifically,
you should ensure that they will work
under the CS CLIC lab environment. You may do a remote login to
clic.cs.columbia.edu with your CS account to test them
out. (Note: IPv6 functionalities may be tested on erlang.cs.columbia.edu and bart.cs.columbia.edu, both are sun machines.) You should not assume that the grader has more sophisticated tools
like J Builder or special libraries that don't come with common tools. If you used any other platform (Windows/Solaris), make sure you state clearly in your README/Sample outputs file.
- Your submission must consist of all the following
files:
README: There must be a file called README,
which contains any helpful information to the grader on how to run your
program. This includes:
- Your Name and Email: (Very important.)
- Brief description (including algorithms, program flows etc.) of how your implementation satisfies the programming requirements.
- How to Run It: Ideally your program should be self
explaining. But if it is not, explain the inputs and how to control the
various elements of the program.
- Special Features: List special features or
extensions, which you would like the grader to consider.
- Known Bugs and Limitations: List any known bugs,
deficiencies, or limitations with respect to the project specifications. As
a service to the grader, please be complete here.
- File Directory: If you have multiple source or data
files, other than those created by the compiler, please explain the purpose
of each.
Source Files: All the source files and header
files. Do not include systems files that are available on usual Linux systems.
Makefile: You should have a Makefile, which
compiles your program, even when you write your programs in Java. The
grader should just have to enter "make". Any modification to your make file by
the grader is not accepted.
Sample Output: Your sample output file
is extremely important in grading your programming assignments. Please
do checkout Special
notes on Sample Output files for details.
DO NOT INCLUDE: please delete all executable and object
(.o) files prior to submission.
TOP
How to submit ?
Preferred method of HW submission:
- Login to a CLIC machine (by "ssh
clic.cs.columbia.edu"), put all the above mentioned programming part files
and the (plain txt or PDF) written part file under a separate
subdirectory of your home directory and issue the command:
~coms6181/bin/submit
(Note that the command must be executed on a CLIC machine)
- The "submit" program
will 'tar' all the files in the current directory and ship
them over to TA. So you do not need to 'tar' or 'zip'
those files. Once you have submitted the files (and there haven't been
any errors, for whatever reason), you will receive a confirmation message
(via email) to the account from which the homework has been submitted.
This email will contain a listing of all the files that were submitted.
(Check carefully to make sure that all the files you intended on
submitting are listed. Report problems promptly.)
- You can submit multiple times, but the last
submission is what counts. Each submission will be time stamped. If your
last submission passes the deadline but you want to use your grace days,
please alert me in your README file. Otherwise, points will be deducted
accordingly.
If you really cannot use the above method to submit,
do the following:
- Store everything including README, Makefile, source,
sample output etc,
and the (plain txt or PDF) written part file in the programming part
subdirectory and written part subdirectory respectively. Put then a directory whose name
easily identifies you e.g. "./JoeSmith". In particular, avoid names like
"./project1," since it will make it harder for the grader to keep track of
submissions. Be sure to delete any unnecessary files (executable or ".o"
files). Definitely, it is desirable to encapsulate them using 'tar' like the
following:
- Encapsulate everything into one file, either by "taring"
your directory (tar -cvf JoeSmith.tar JoeSmith), and then compress the tar
file using gzip (or compress) (gzip JoeSmith.tar). If tar and gzip are
unavailable, you can also do this with zip (e.g., zip -r JoeSmith JoeSmith).
TOP
Special
notes on Sample Output files:
The main purpose of having this sample output/test file is
to protect your programming work and provide a ground for fair grading.
Essentially the sample output/test file should serve as a self-proof of the
functionality of your codes and show that your codes meet all (or part) of the
programming requirements. The fact is that I have experienced huge difficulties
(believe it or not) in testing many of the submitted programs. There could be
all sorts of reasons. In many situations these might well not be the student's
fault ... But I can't simply say "No" or "Yes" to these programs because doing
so might be either unfair to the programmer or to the rest of the
class.
Therefore in the sample output/test file, I expect you to provide the detailed
testing environment (time, platform, machines .... e.g., you tested in Clic
between Helsinki and Budapest etc..) And the screen dump of the testing (from
which machine, what kind of command with which argument is executed, what are
the outputs ....) and any other related information. It will be helpful, if you
can print additional explanatory notes on the screen about the test, although
that is not strictly required. But in any case, you should give a brief
explanation of what is going on. If there were problems, why did they happen and
what could be the causes .... In addition, when you claim your program supports
a feature, e.g. multicast, or IPv6, you should provide testing outputs using
e.g. multicast addresses, IPv6 addresses .... If you had problem doing that,
explain why, just be candid, whether it is due to a programming flaw or system
problem, or whatsoever.
Again the basic idea is to provide enough information that is necessary to
maximize the possibility of my successful testing of your program according to
the programming requirements. So all of you can
(hopefully) get the credits you deserve.
TOP
Updated Jan 29, 2004 TA CS6181