Exercise 2: Building Reliable File Transfer – Part 2

In this C/Java exercise you will implement reliable file transfer between a client and a server (from the client to the server) using UDP.

Introduction:

This exercise is based on ex. 2 – part 1. You are welcome to use your code and change only the relevant parts.

Please follow the course forum, since updates to the exercise will be sent there.

Synopsis:

For running the server:

sruftp server-port 

For running the client:

cruftp server-port  server-hostname filename-to-transfer

server-port:                 is the port used by the server
server-hostname:        is the host name of the server
filename-to-transfer:   is the name of the file to transfer from the client to the server, it must reside in the same directory as the client was executed from.
    It will be copied to the same directory as the server was executed from with the same name as it had on the client. If such a file already exists on the server then it should be overwritten.

Basic requirements of the server design:

• The server should handle clients using a single process, using the select() system call or using several threads
• It is OK to use non-blocking sockets IO (if needed).
• The server should be resilient to client failures.
• The server should store the incoming packets in a buffer, order them by their order and check for missing packets. You are welcome to use any protocol you design, by the server either acking packets or naking missing packets.
• Handling one client correctly is a basic requirement from the server. A bonus will be given to those of you who will implement handling of multiple clients (the bonus will not exceed 100).
• You are welcome to implement the reliable blast UDP protocol http://www.evl.uic.edu/cavern/papers/cluster2002.pdf or design a simpler but correct protocol.

Basic requirements of the client design:

• The client initiates the file transfer. This time the file transfer will be done over UDP. You MUST handle the case of lossy channel, packet duplicates and packets received in the wrong order.

Testing Your Program:

• Run the server on one machine. Run the client and send a file to the server. Use “diff” command to verify the file was created properly, and has the same size.
• Run the script ~com1/www/checkme_ex2b.sh to verify your tar structure

Error Handling:

• You can assume the input parameters are correct. .
• In case of an unrecoverable error (e.g., if  the program can't open a socket), the program must exit(1) and write an error to STDERR. In case of success the client program should return 0. The server should not exit in case of client errors, just close the misbehaving clients.

Useful system calls:

socket, bind, connect, listen, accept, send, recv, select, close, inet_addr, htons, ntohs, gethostbyname, sendto, recvfrom, sigignore, shutdown, gdb

General Tips:

• As always remember to close() all sockets.
• You should handle SIGPIPE as was done in the previous exercise.
• Remember to use htons(), htonl() etc. sys calls where needed.
• No need to allocate dynamic memory. It is OK to bound the buffer size to 100K, receive all parts of the buffer and then save it to disk. Then get the next buffer etc.

What to submit

• The files sruftp.c and cruftp.c. (Or in Java: Sruftp.java and Cruftp.java
• (For the c programs: A Makefile which compiles the executables
  cruftp and sruftp (should work on the system Linux computers like inferno)
• A README documenting your protocol.
• Example Makefile for C is found here Example Makefile for Java Makefile
• Read closely the course submission guidelines regarding creation of the tar file.