CS143 Programming Assignment One CS143 Programming Assignment One The goal of this assignment is for you to design and implement a simple file transfer protocol. Because you'll be using unreliable UDP service, you'll have to use some of the ideas that make higher-level protocols such as TCP and NFS reliable. Later assignments will build on these ideas. You should write two programs, a client and a server. You start the server on the host from which you want to read files, with a port chosen by you. If you choose port 27011, you might start the server thus, after creating a test file:
scws32% echo hello > testfile
scws32% ./server 27011
Log into another computer to read the file over the network from the server program:
scws40% ./client scws32.harvard.edu 27011 testfile
hello
scws40%
In order to avoid conflicts with other students, you should test your programs on randomly selected ports and workstations; don't just use scws32 and port 27011. The HP workstations at the Science Center are called scws23.harvard.edu through scws47. You can use ports from 7000 to 32000. Requirements We'll be running your programs as part of grading. In order that you solve the desired problem and we be able to verify this, please adhere to the following requirements: Your program must be compilable by the gcc C compiler on HP-UX. Your client must be called client, and your server server. Your client and server must communicate with UDP, not TCP. That is, you must use AF_INET/SOCK_DGRAM sockets. The client program must take three arguments, the name of the host on which the server runs, the port number on which the server is listening, and a file name to fetch. The client program may not directly read any files -- it must fetch the desired file by talking over the network to the server. If all goes well, the client should emit the contents of the requested file on its standard output and call exit(0). Nothing but the file contents should ever be printed on the standard output. If an un-recoverable error occurs, the client should print a message on its standard error and call exit(1). Your client may assume that any packet it receives from the server's port and IP address was really sent from the server. You may also assume that any packet your programs receive was sent less than five seconds previously. Neither of these are true of real networks. The server program must take one argument, a port number on which to listen for packets from the client. Your server should be able to handle multiple simultaneous clients. Your server should be able to handle an unlimited series of separate file requests. For security, your server must reject any request with a file name containing /. You may want to run your server in a directory containing only files that you don't mind random people on the net stealing. The server must either ignore or reply to each packet it receives. It is not allowed to crash or quit just because it receives a packet filled with garbage. The client and server must be able to run on different hosts and still communicate. Your protocol must be able to transfer files of at least a gigabyte. Your protocol must correctly transfer the file even if the network drops, duplicates, or re-orders some packets. You may assume that any packet you receive contains the same bytes that the sender sent. If your client or server does not seem to be able to contact the other party, you should avoid sending more than one packet per second. In any case you should avoid sending many more bytes over the network than there are bytes in the file. Hints Look here for some references on sockets programming on UNIX. You will want to use sequence numbers to recover from duplicated or re-ordered packets. You will want to use time-out and re-transmission to deal with lost packets. We've written some sample code for you, which you may incorporate into your assignment if you wish: A UDP demo, on which you could base your client and server. nread.c reads a small chunk of data from a given offset in a file. timeread.c, which may help you implement read with time-out. UNIX imposes a limit on the size of UDP packets -- a thousand bytes will work, but ten thousand probably won't. You may find it convenient for the client to drive the conversation with the server. That is, the client should send requests to the server, each request for one packet's worth of data from the file. The server needn't keep any per-client state: each time it gets a request, it can open the file, read a packet's worth of data, close the file, and send the data. Don't be tempted to use the fork system call. When you hand in your code (see the next section), you'll have to give us a Makefile. Here is a sample; it will cause client.c and server.c to be compiled when you type make:
CC = gcc
CFLAGS = -g
all : client server
Make your algorithms and code clean. We won't grade your coding style. However, if we suspect your code doesn't completely work but we cannot understand it, we won't cut you much slack. What to Hand In This assignment is due at 1:00pm on Wednesday Oct 2 1996. Mail a shar file containing a Makefile and your source files to cs143-pa-one@eecs.harvard.edu. We must be able to simply un-shar it, type make, and run the programs client and server. To create a shar file from your files and mail it to us, try something like this (but the arguments to shar should be the names of your source files):
scws40% shar client.c server.c common.h Makefile > shar.out
scws40% Mail cs143-pa-one@eecs.harvard.edu < shar.out
The late policy for the entire course is that you get a total of five late days. You may use them for any assignment. For instance, you could hand one assignment in an hour late, another 95 hours late, and the others on time. When you've used up all your late time, we won't accept late homework at all except if you have a terrible emergency. While you may discuss this assignment with other CS143 students or the TFs, everything you hand in must be your own work.
