CS-375: Spring 2003

Trivial File Transfer Protocol (TFTP) Server

Your assignment is to write a UDP based TFTP Server. Your server must be able to handle Read and Write Requests that use transfer mode "octet". The focus of this project is UDP programming, including timeouts and retransmissions, so you should be able to leverage some of what you learned (along with some of your code) from Project 3. Your server must work with standard TFTP clients (such as the program tftp found on the Linux machines). Refer to RFC 1350 for a description of the TFTP protocol. The operation of the peer-to-peer protocol will not be repeated here. You must use the RFC to determine the message formats and expected operation of the protocol.

You are allowed to work in teams of size two on this assignment. Both members must pull their weight, and at the time of project submission, I will request both a self- and partner- evaluation of contribution. Both members of the team must fully understand the TFTP protocol.

What is and is not required:

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 '.' (note that this also disallows '..'). Legal filenames should be interpreted as being relative to the current working directory of the server process.

The second argument to your server should be the directory to start in. This will be specified in argv[2]. You can use the chdir system call to change the current working directory of a process (to get specifics, invoke 'man 2 chdir'). You can assume that the directory specified will either be an absolute path name, or will be the hyphen character ('-'). If it is the latter, the current directory should not be changed.

Your server must support (only) the file transfer mode "octet" (binary transfer).

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.

For full credit, your server must support Write Requests. In order to provide some level of security, the server must enforce the following two constraints on write requests:

	As with Read requests, you should reject any request for a file whose name starts with a '/' or '.'. Thus all legal file requests should be relative to the current working directory of the server.
	The Write request should only be allowed if the specified file is a "regular file" and already exists. So our Write Request is, in effect, an overwrite operation. Note that the stat system call (see 'man 2 stat') should allow you to check if a file exists and is a regular file.

If both of these constraints are satisfied, the file should be truncated and written appropriately to the TFTP specification.

For full credit, your server must be concurrent. I must be able to transfer files from multiple clients at the same time.

I 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.

Server Output

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):

> proj4 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

Deliverables

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:

	The names of the team.
	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 me know how you would plan to do it!
	Anything else you think might be useful, such as what you learned, what you had trouble with, if the project was too hard or too easy, etc.

Grading

Your server will be tested to make sure it works properly. I 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. I 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%

For testing purposes, you may access some of the files I used for project 3:

Large ASCII file

Large Binary file