| NetProg 2002 HW3 |
| Project Description | Deliverables | Grading | Submission | Notes & Hints |
Your assignment is to write a UDP based TFTP Server.
Your server must be
able to handle Read Requests that use transfer mode "octet". The focus
of this project is UDP programming, including timeouts and
retransmissions, not on supporting all of TFTP. Your server must work
with standard TFTP clients (such as the program tftp
found on the CS Solaris machines). Refer to RFC 1350
for a description of the TFTP protocol.
Your server must use a port number specified as the first command line parameter (from argv[1]). Your program will be run by an automated system that requires that your server understand that it should use the port number specified on the command line!
Your server must handle Read Requests. You should reject any request for a file whose name starts with a '/' or '.'. Legal filenames should be interpreted as being relative to the current working directory of the server process.
Your server must support the file transfer mode "octet" (binary transfer).
Your server does not need to support Write Requests
Your server does not need to support "ASCII" transfer mode.
Your server must support the TFTP protocol including timeout and retransmission. There must be a maximum number of retries so that your server eventually gives up on the client if nothing is received for a long time. I'd suggest using a maximum of 5 retries, with a timeout for each of 5 seconds.
Your server must be concurrent. We must be able to transfer files from multiple clients at the same time.
We must not be able to kill your server by sending silly stuff from the client (including very long messages).
Your server must not have memory leaks or create zombie processes.
Your server should emulate the "trace" functionality of TFTP clients, that is - you should print one line to stdout every time a TFTP message is received or sent by your server. An example (just to give you an idea of the kind of info expected):
> hw3 1234 RRQ received from 128.213.8.240, filename: foo DATA message sent to 128.213.8.240, block #0 ACK received from 128.213.8.240, block #0 DATA message sent to 128.213.8.240, block #1 Timeout DATA message sent to 128.213.8.240, block #1 ACK received from 128.213.8.240, block #1 |
You should submit all source code files necessary to build your server. If you use a Makefile please include it, if not, you need to include instructions on how to build your server. Your submission must also include a file named README that includes the following:
Your Name
A list of files and a 1-line description of the contents of each file.
References to any borrowed code (the source code must also include this information).
A description of any known problems. If you think you know how to solve the problem(s) and simply didn't have time to do so - let us know how!
Anything else you think might be useful to us, such as what you learned, what you had trouble with, if the project was too hard or too easy, etc.
Your server will be tested to make sure it works properly. We will use a test client that will do it's best to mess up your server by sending nonsense, occasionally ignoring DATA messages (simulating a lost datagram), responding with inappropriate ACKS, quitting in the middle of a transaction, etc. We will compare the file received by the client to the original file to make sure the transfer worked properly (size and content must match!).
Your testing should include using a tftp client. You can use ^Z to suspend the client in the middle of a (long) file transfer - this can simulate what would happen if a datagram was lost (your server should timeout waiting for an ACK and resend data).
Points will be awarded as follows (partial credit is available for each item):
| File transfer works properly with a single, polite client. | 30% |
|---|---|
| Server works properly with multiple (concurrent) polite clients. | 15% |
| Server works properly (resumes a transfer properly) when a few datagrams are lost. | 15% |
| Server works properly with clients that send garbage (server doesn't crash, recovers ongoing transfers when possible) | 15% |
| Style/readability | 25% |
IMPORTANT NOTES ON GRADING:
We will deduct points for memory leaks and zombies!
Submission of your homework is via email, the general idea is to send an email message with all your files as attachments. There is an automated email submission system that will respond to your submission right away, so you will have a record that we got your files.
All projects must be submitted via email to netprog-submit@cs.rpi.edu. The subject line of the submission message should contain a single number indicating the project number (3 for HW2). You must include your files as attachments, feel free to send a zip-file or a tar file.
Don't send compiled code!
You can expect a return email indicating receipt of your project submission immediately. This receipt will include a list of all the files that were successfully extracted by the submission script - please look over the receipt carefully to make sure your submission worked.
Multiple Submissions: You can resubmit up to 10 times for each project, we will always grade the last submission received unless you tell us otherwise.
Read the RFC!
There is a TFTP server running on monte.cs.rpi.edu (on port
69) that you can play with using any tftp client. The server can send 3
different files, named small, medium and
large. There are copies of these file on the CS
machines at ~hollingd/tftp.