Return-Path: lccheung@usc.edu
Delivery-Date: Wed Jan 24 23:56:41 2007
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on merlot.usc.edu
X-Spam-Level: 
X-Spam-Status: No, score=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 
	autolearn=ham version=3.1.3
Received: from msg-mx0.usc.edu (msg-mx0.usc.edu [128.125.137.5])
	by merlot.usc.edu (8.13.5/8.13.5) with ESMTP id l0P7ufwJ031276
	for <cs551@merlot.usc.edu>; Wed, 24 Jan 2007 23:56:41 -0800
Received: from lesliee502e195 ([71.130.125.254])
 by msg-mx0.usc.edu (Sun Java System Messaging Server 6.2-7.05 (built Sep  5
 2006)) with ESMTPSA id <0JCE007FAZB1O380@msg-mx0.usc.edu> for
 cs551@merlot.usc.edu; Wed, 24 Jan 2007 23:54:40 -0800 (PST)
Date: Wed, 24 Jan 2007 23:54:30 -0800
From: Leslie Cheung <lccheung@usc.edu>
Subject: warmup project 1
Sender: lccheung@usc.edu
To: cs551@merlot.usc.edu
Message-id: <0JCE007FBZB2O380@msg-mx0.usc.edu>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Thread-index: AcdAVgrP5yTyQYzES36BcbuG6rrE/Q==

Hi all,

Here are answers to some questions I answered during my office hour, and I
think this might be of interest to the rest of the class...

1. README
Things I expect in README are (a) any design decisions you made that is not
in the spec (e.g., how do you choose a timeout value, how do you handle
malicious clients/servers, etc); (b) Known bugs (not required, but it's nice
to have so the grader knows what to expect); (c) any deviation from the spec
(e.g., the grader need to type something other than "make server" to create
an executable file for the server); and (d) References (e.g., you use some
code you find on a web site)

Please note that by putting design decisions README does not exempt you from
losing points. For example, if you set the timeout value to 2 hours and you
put that in README, the grader might think this is not a good decision, and
takes points off for those test cases.

If you want to put additional info in the README for your own references
(e.g., what this project does), that's ok. You can assume that the grader
has a copy of the spec, so you don't have to repeat what's in the spec.

2. Separate Compilation
(a) Please do not put any "implementation" of any function in .h files. This
is considered "putting the bulk of your code in a .h file". What you should
do is to put only function or variable declarations in a .h file (hello.h),
and put the implementation of the functions in the corresponding .c file
(hello.c). 

(b) You are required to divide server code into multiple .c files (for
example, server.c and server_functions.c). If you put all the server code in
one file (server.c), you'll lose 5 points. The files do not have to be of
"similar" size. For example, you can put most of the code in "server.c", and
just one function in "server_functions.c". We are requiring you to divide
code into multiple files to make sure you understand separate compilation,
and how to create an executable from multiple .c files. This also applies to
client code. 

(c) For each .c files, you have to generate a .o file (using the "-c" option
of gcc), and then link all the .o files to create an executable for
server/client.

3. Getting filesize
In one of the test cases in our grading guideline (/etc/shadow), you do not
have read access to the file, but you are able to get the filesize. If you
try to open the file and count the number of bytes, you'll get "Permission
denied" and not able to get the filesize. You should use "stat" of "fstat"
to get the size of the file. See the man page on nunki for details ("man -s
2 stat").

I hope this helps.

--Leslie
