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.