One of the great advantages of living in a networked world is the ability to move information (files) quickly and cheaply from one place to another. For example, if you need a new driver for your video card, just download it from the manufacturer's ftp/web site (you used to have to call up and order disks with your credit card L ). The ftp program is one of the original (and still most popular) utilities for transferring files across a network.

All communications between the client and server after the initial 128 byes are encrypted. Notice that all messages between the client and server terminate with '\n', so the easiest way to read a message is one character at a time until '\n' is received.

1. The client sends a string of the form "auth <username> <password>\n" to the server (Note: the NULL character at the end of strings is not transmitted).
2. The server opens a local file authenticate.ftp and searches for the name <username>. If found, it uses the UNIX system call crypt() to compare <password> with the corresponding password from the authentication file.
3. If successful, the server returns "auth OK\n" and the programs continue.
4. If unsuccessful, the server returns "auth FAILED\n" and terminates the connection with the client.

The authentication file, authenticate.ftp, is a text file where each line contains authentication information of the form

It is assumed that <username> contains only the characters a-z, A-Z and 0-9. Lines are terminated with a single '\n' character. The <encryptedPassword> is the result of passing some plain-text password through the UNIX system call crypt(). I will provide an example of doing this.

When the user wishes to transfer a file to the remote machine, s/he types "put <filename>". The following exchange then takes place:

1. The client sends to the server "put <fileName> <fileSize>\n" where <fileSize> is an ASCII representation of the file's size in bytes.
2. The server prepares the destination file for writing and responds with "put READY\n".
3. The client, upon receiving acknowledgement from the server, sends the file data.
4. When the server has received <fileSize> bytes worth of data, it replies with "put OK\n".
5. If the server is unable to accept the file, it replies to step 1 with "put FAILED\n". If the server is able to accept the file, but unable to write all the data in to the file, it should still read all of the data, and then respond with "put FAILED\n".

When the user wishes to transfer a file from the remote machine, s/he types "get <filename>". The following exchange then takes place:

1. The client first opens the desired filename for writing, and then sends to the server "get <fileName>\n"
2. The server prepares the destination file for writing and responds with "get READY <fileSize>\n" where <fileSize> is an ASCII representation of the file's size in bytes.
3. When the server then proceeds to send <fileSize> bytes worth of data. The client replies with "get OK\n" (regardless of whether all the data was written to the destination file - it only reports this error to the user).
4. If the server is unable to send the file, it replies to step 1 with "get FAILED\n".

It is necessary to allow the user to list the available files. The user types "dirlist" to the client, and the following exchange takes place:

1. The client sends the string "dirlist\n" to the server.
2. The server replies with "dirlist OK\n" followed by "<DirName>\n" where <DirName> is the absolute pathname of the current ftp directory of the thread managing the connection. The server then sends the following for each file: "<fileName> <fileSize> <LastModifiedDate> <Filetype> <Readable>\n". The first three items are self explanatory. <fileType> is one of "R" (for 'regular'), "D" (for 'directory') or "O" (for 'other'). <Readable> is "readable" if the file is readable by the server process, or "not-readable" otherwise. When the last file has been sent, the server sends an additional "\n".
3. If for any reason the server is unable to send the information, it returns "dirlist FAILED\n".
4. The client displays the information returned by the server until two consecutive '\n' characters are received.

When the client first connects, the server thread starts in the directory from which the server was run. If the client wishes to transfer files from another directory, they must first change the current directory for their connection. When the user wishes to change his/her working ftp directory s/he types "cd <newDir>" to the client program. The following exchange takes place between the client and server:

1. The client send "cd <newDir>\n" to the server.
2. The server thread handling the connection attempts to open the new directory for reading. If successful it returns "cd OK\n", otherwise it returns "cd FAILED\n".

Note that using the command chdir() will change the current working directory for all threads, so each thread must instead maintain it's own record of its current directory.

<username> the user name for the user on the remote system

<hostname> the name of the remote system to login to

<port> the port on which the server (sFtpS) is listening

The getuid() function returns the user ID of the person running sFtp. Since every user has a unique user ID, this ensures that no two CSC209 students will attempt to bind the same port, even if they run sFtp on the same machine.

I will provide the RC4 encryption code to make this assignment simpler. All files will be found in /u/csc209h/include and /u/csc209h/lib.

libRC4.a, rc4.h: this header file together with its library will allow you to perform RC4 encryption/decryption of a character stream. In /u/csc209h/src I will provide the file TestRC4.c which will demonstrate the use of this library. Note that I have changed this library since last term, so please use the up to date versions.

I will also provide a utility to add new users to the file authenticate.ftp.

• Use at least 10 assert() statements. These must be used properly, so read the style page on the course website if you are unsure.
• You must use select() in your client; marks will be deducted for improper use (if in doubt, ask).
• You may not use fork()/exec(); all concurrency must be achieved using POSIX threads.
• You must use multiple files, and provide a makefile, which compiles both your client and server programs.
• You may only use INET domain sockets.
• Your code must work interchangeably with a client and server that I will provide no later than March 27th. That is, your client must work with my server, and your server must work with my client

1. To make the server port available for re-use immediately upon termination of the server, include the following code fragment in your server before binding the socket:
   int opt = 1 ;
   if (setsockopt(soc, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)))
   {
   perror("Unable to set server socket for re-use! "); exit(1);
   }
   where soc is the socket your server will be listening on.
2. When you write data to a socket, don’t write NULL characters that are not actually part of the data.
3. Don’t try and write the whole program at once (remember, Rome wasn’t built in a day). Instead, break it down into manageable chunks, and code/test each chunk in some order. A sample breakdown might be:
   * write an unencrypted client server that only supports authentication
   * add the "Directory Listing" command
   * add the "Change Directory" command
   * add the file transfer from server to client (this one is easier)
   * add the file transfer from client to server
   * add encryption [note: it may be best to encapsulate all of your reading/writing to the sockets in a single functions to make adding encryption easier at the end]
   Of course, each of these components can be broken down into smaller subtasks. It’s better to hand in a working but incomplete program than a complete program that doesn’t work at all.
4. To link the libraries, include the following parameters to gcc:
   -L/u/csc209h/lib –lRC4
   
   Important: you must include these parameters before the name of the files to be linked.

When you are ready to submit your programs, you will use tar to combine all your source files (*.c and *.h) and your makefile into a single file named secureFtp.tar. Use gzip to compress this file, thus creating secureFtp.tar.gz. It's probably a good idea to attempt uncompressing and un-tar-ing a copy of this file in a separate directory to make sure the tar operation worked.

You must hand in a printed version of your program (failure to submit a printout will result in a mark of 0/30 for style), as well as submitting it electronically on CDF using "submit -N a4 csc209h secureFtp.tar.gz". You can overwrite a previous submission by adding the "-f" switch to the submit command. No external documentation is required, but your program should be well documented.