| NetProg Spring 2004 HW3 |
| Project Description | Deliverables | Grading | Submitting | Resources |
Submit to WebCT drop box.Late Penalty: 10%/dayHW3 can be done in C, C++ or Java. You must tell Dave ahead of time if you plan to use Java. |
Important Notes:
|
Your assignment is to write a TFTP server that can handle Read Requests (RRQs). Your server does not need to be capable of handling Write Requests (WRQs). Your server must be capable of supporting multiple, simultaneous clients (there can me more than one client in the middle of a file transfer at the same time). You need to provide an implementation of the TFTP Protocol (as defined in RFC 1350), including support for file transfer modes "netascii" and "octet". Your server should assume Unix line termination is used for the local storage of ASCII text files (write your server so that it assumes local line termination is a single '\n').
Part of implementing the protocol requires that you can support time-out and retransmission. Your server should set the timeout period to (roughly) 5 seconds and should retransmit a total of 5 times before giving up. There are a number of ways to handle timeouts, using select() is probably the easiest and most portable.
Your server should work with any TFTP client, including the
program tftp installed on the CS Sun workstations. It
may be useful to understand some of the options possible with this
client, in particular the "verbose" and "trace" options (which result
in the client printing out information about every TFTP message sent
and received). There will be a demonstration of using these options in
class, there is also information in the man page for tftp.
When testing your server you can simulate the loss of messages by suspending the client during an ongoing TFTP conversation. On the CS Suns, you can suspend a process by pressing ctrl-Z. When running a TFTP client, this will suspend the client and return you to the shell. To bring the client back to life you can use the shell job control commands, the command "fg" will bring the last suspended process to the foreground ("fg" stands for "foreground"). Dave will demonstrate this in class.
There is a TFTP server running on monte.cs.rpi.edu (UDP port 69) in
case you want to play with a client and server. There are three files
available from this server (the server will not service WRQs). The
file names are small (217 bytes ASCII text), medium
(32768 bytes, ASCII text) and large (1MB binary
data).
You must submit all the source code necessary for us to build your tftp server. You must also include a Makefile that can be used to build your server on the CS Sun workstations. If you don't know how to use make or create a Makefile, refer to the sample TCP client and server code available via the course home page (simptcp). Feel free to ask for help creating a Makefile - send mail to netprog@cs.rpi.edu.
You must also include in your submission a file named
README that includes your name and a brief description of
your submission, including the name of each file submitted along with
a one line description of what is in the file. If your code is not
complete, tell us what works and what doesn't. If you are submitting
code that does not compile, please tell us that as well. If any of
your code was written by someone else, you are required to tell us
about it (this must also be documented in the code itself). Finally,
feel free to include a description of any problems you had or anything
else you think might be helpful to us.
Your project will be tested to make sure it works properly. Will will use a standard TFTP client as well as custom clients. As with any server, you need to make sure your server does not crash as a result of receiving unexpected messages from the client!
Here is a rough breakdown of the grading:
| RRQ binary transfer ("octet") when everything goes well - no lost messages. |
30% |
| RRQ ASCII transfer ("netascii") when everything goes well. |
10% |
| Timeout/Retransmission (dealing with lost messages) | 10% |
| Support for concurrency | 15% |
| Dealing with impolite requests, unexpected messages | 10% |
| Error handling, Style/Code structure, etc. | 25% |
NOTE: 25% of your homework grade depends on the how "well your code is written". These points include the following:
Error handling (check every system call for an error!).
Safe code (avoiding buffer overflow, etc).
How well we can understand your code. There is no required format for your code, there is no requirement like "you must have one comment for every 2.35 lines of code". Feel free to provide what ever level of commenting you believe is appropriate to make sure that other competent programmers could easily understand and make changes to your code.
IMPORTANT: It is not acceptable to write this project in a single function (or even just a couple of functions).
Submission of your homework is via WebCT dropbox for HW3. Don't send compiled code!