CSCI-4220 Network Programming

Project 3 - TFTP Server
Due Date: Feb 25th

Submission Instructions

TFTP Server

This project involves the creation of a TFTP server. Your server should be based on UDP and should support the TFTP protocol as specified in RFC 783 with the following exception:

• Don't worry about file modes - assume everything is in binary ("octet" mode). Your server should send raw DATA without interpreting any of the contents of a file, and should assume that any received DATA should simply be stored in a file without interpretation. In other words - ignore the file mode specifier on all requests and assume it is set to "octet". When testing you need to specify "octet" mode to a TFTP client or it will do translation!

Your server must be able to handle multiple concurrent clients.

Server Output

Your server should print (to stdout) out the port number it is running on as soon as it starts. Using a fixed port number may make it difficult for us to grade (and for you to debug), so we suggest you allow the operating system to assign you any available UDP port. The initial line printed by your program should include the port number and nothing else (not "Port = 3838\n", just "3838\n"). Your program will be run by an automated system that expects this output.

Your server does not need to provide any additional output, although we encourage you to leave any debugging print statements in place (it may help us figure out what your server is doing).

Servers are forever!

Your server must never die! For this project your code must be capable of running forever. This means you must take care of all possible errors, and that you must make sure your server does not gobble up any system resources for each new client without ever releasing these resources (you should clean up after children, etc).

Deliverables

You should submit all the source code necessary to build your server and a makefile. Submission instructions are here. You must also include a brief writeup in a file named README that includes the following:

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

Computer Accounts

You must not use RCS! Make sure your code builds and runs on the CS machines.

Tips, Hints, Suggestions

• Read RFC 783
• Use the program "tftp" as a client for testing. There is no reason to write your own client. Use "man tftp" for more information about how to use the tftp client program.
• The machines ipx machines all have tftp servers running so you can get the hang of using tftp. There are 3 files you can read, named small, medium and large. You can't "put" any files. Here is an example session showing how to turn on trace mode (shows each datagram sent and received):

  /amd/stagger/home1/b/hollingd tftp ipx1.cs.rpi.edu tftp> ? Commands may be abbreviated. Commands are: connect connect to remote tftp mode set file transfer mode put send file get receive file quit exit tftp verbose toggle verbose mode trace toggle packet tracing status show current status binary set mode to octet ascii set mode to netascii rexmt set per-packet retransmission timeout timeout set total retransmission timeout ? print help information tftp> trace Packet tracing on. tftp> verbose Verbose mode on. tftp> binary mode set to octet tftp> get small getting from ipx1.cs.rpi.edu:small to small [octet] sent RRQ <file=small, mode=octet> received DATA <block=1, 512 bytes> sent ACK <block=1> received DATA <block=2, 512 bytes> sent ACK <block=2> received DATA <block=3, 0 bytes> Received 1024 bytes in 0.5 seconds [16384 bits/sec] tftp>

  The tftp server installed on these machines will not accept queries from machines outside of the domain cs.rpi.edu (you have to be on a CS machine to access these servers).
• The RFC does not specify the timeout values (how long to wait before retransmitting, how long to wait before giving up). We suggest something like 1 second timeout before retransmission and a total of 5 seconds before giving up.
• To test how your server handles lost packets, you can simply suspend the client (with ^Z) during a long transfer. As long as the client is resumed soon - your server should be able to finish the transaction.

All questions should be sent to "netprog@cs.rpi.edu".