Total Points: 100 points
Goal: Program a Prototype of a FTP application using TCP
Assigned: September 17
Due: October 3 by the beginning of class. Grouping: To be completed by a group
Background
In this programming assignment, you will implement the client and server sides of a simple File Transfer Protocol (FTP) application. The file transfer itself will take place using TCP with the client determining the operation to be performed (requesting/downloading a particular file, uploading a file, deleting a file, creating a new directory, removing a directory, changing to a different directory, obtaining a directory listing, or closing the connection). The server should respond appropriately to the specific command. The specifics of the protocol are detailed in this handout. Note: please refer to appendix A for the port number assigned to you (the same as PG1).
Protocol - Simple File Transfer
Server opens port, and goes into "wait for connection" state.
Client connects to the server on the appropriate port.
Server goes into "wait for operation from client" state and waits for operation command from the client.
Client goes into "prompt user for operation" state and prompts user for operation.
DL: Note: Please test DL with the three test files (i.e., LargeFile.mp4, MediumFile.pdf, SmallFile.txt) discussed in the general notes.
Client sends operation (DL) to download a file from the server.
Client sends the length of the file name (short int) followed by the file name (character string).
Server decodes what it receives, and checks to see if the file exists in its local directory.
If the file exists:
Server first calculates the md5 hash of the file using md5sum system utility and returns the md5 hash to the client. (Please refer to the general notes for more details about MD5 hash.)
Serve also returns the size of the file to the client as a 32-bit int in another message.
If the file does not exist, server will return a negative 1 (32-bit int). After that, the server should return to the "wait for operation from client" state.
Client receives 32-bit file length from server.
Client should decode the 32-bit value.
If the value is negative one, user should be informed that the file does not exist on the server. Client should return to "prompt user for operation" state.
If the value is not a negative 1, save the value as the file size for later use.
Server sends the file to client.
Client reads md5 hash from server.
Client reads "file size" bytes from server.
The client saves the file to disk as "file name"
The client calculates the md5 hash of the file received (using the md5sum system utility), compares it to the hash the server sent, and displays a confirmation if they match or an error if they do not.
Inform user that the transfer was
successful, and return to "prompt user for operation" state. The
client displays throughput results and MD5 hash for the transfer.
UP:
Client sends operation (UP) to upload a local file to a server.
Client sends the length of the file name which will be sent (short int) followed by the file name (character string). Note: you can create a local file called "upload.txt" with random strings to test the UP operation.
Server receives the above information, decodes file name size and file name, and acknowledges that it is ready to receive (it is up to you how to do the acknowledgment).
Client replies with a 32-bit value which is the size of the file (in bytes).
Server receives and decodes the 32 bit value.
Server enters the loop to receive file
Client sends file to server. Server reads "file size" bytes from client and saves them to disk as "filename".
Server computes throughput results for the transfer and the md5 hash of the file.
Server sends the throughput results and hash to the client. This information should be used by the client to inform user that the transfer was successful or not (i.e., if the hash from the server matches the hash of the local file). If the transfer was successful, client displays the throughput information and MD5 hash of the transfer. Otherwise, client informs the user the transfer failed. Finally, client returns to "prompt user for operation" state.
RM:
Client sends operation (RM) to delete a file from the server. Note: you can create a test file called "delete.txt" with random strings in the server directory to test the RM operation.
Client sends the length of the file name which will be sent (short int) followed by the file name (character string).
Server receives the above information, decodes file name size and file name, and checks if the file to be deleted exists or not.
If the file exists, the server sends a positive confirm (integer value 1) back to the client.
If the file does not exit, the server sends a negative confirm (integer value -1) back to the
client.
Client receives the confirm from the server.
If the confirm is negative, it prints out "The file does not exist on server" and returns to
"prompt user for operation" state.
If the confirm is positive, the client further asks user to confirm if she/he wants to delete
the file: "Yes" to delete, "No" to ignore. The client then sends the user's confirm (i.e., "Yes" or
"No") back to the server.
If the user's confirm is "Yes", the client waits for the server to send the confirm of file
deletion.
If the user's confirm is "No", the client prints out "Delete abandoned by the user!" and
returns to "prompt user for operation" state.
The server waits for the delete confirm sent by the client.
If the confirm is "Yes", the server deletes the requested file and returns an acknowledgement to the client to indicate the success or failure of file deletion operation.
If the confirm is "No", the server returns to "wait for operation from client" state.
LS:
Client sends operation (LS) to list the directory at the server.
Server obtains listing of it's directory, including both the permission settings and the name of each file (e.g. "-rwxr-xr-x 1 netid dip 21K Aug 22 12:58 test.txt" or simply "-rwxr-xr-x test.txt"
)
Server computes the size of directory listing and sends the size to client as a 32 bit int.
Client receives the size, and goes into a loop to read directory listing.
Once listing is received, client displays listing to user.
Client and server return to "prompt user for operation" and "wait for operation from client" state respectively.
MKDIR:
Client sends operation (MKDIR) to make a directory at the server.
Client sends the length of the directory name which will be sent (short int) followed by the directory name (character string).
Server receives the above information, decodes directory name size and directory name, and checks if the directory to be created exists or not.
If the directory exists, the server sends a negative confirm (integer value -2) back to the client.
If the directory does not exit, the server sends a positive confirm (integer value 1) back to the client if the directory is successfully created; otherwise, the server sends a negative confirm (integer value -1) back to the client.
Client receives the confirm from the server.
If the confirm is negative (-2), it prints out "The directory already exists on server" and returns to "prompt user for operation/wait for operation" state.
If the confirm is negative (-1), it prints out "Error in making directory" and returns to "prompt user for operation/wait for operation" state.
If the confirm is positive, the client prints out "The directory was successfully made" and returns to "prompt user for operation/wait for operation" state.
RMDIR:
Client sends operation (RMDIR) to remove a directory at the server. Note: Directory must be empty for RMDIR to work.
Client sends the length of the directory name which will be sent (short int) followed by the directory name (character string).
Server receives the above information, decodes directory name size and directory name, and checks if the directory to be deleted exists or not.
If the directory exists and is empty, the server sends a positive confirm (integer value 1) back to the client.
If the directory does not exit, the server sends a negative confirm (integer value -1) back to the client.
If the directory exists and is not empty, the server sends a negative confirm (integer value -2) back to the client.
Client receives the confirm from the server.
If the confirm is negative (-1), it prints out "The directory does not exist on server" and returns to "prompt user for operation/wait for operation" state.
If the confirm is negative (-2), it prints out "The directory is not empty" and returns to "prompt user for operation/wait for operation" state.
If the confirm is positive, the client further asks user to confirm if she/he wants to delete the directory: "Yes" to delete, "No" to ignore. The client then sends the user's confirm (i.e., "Yes" or "No") back to the server.
If the user's confirm is "Yes" the client waits for the server to send the confirm of directory deletion.
If the user's confirm is "No" the client prints out "Delete abandoned by the user!" and returns to prompt user for operation/wait for operation state.
The server waits for the delete confirm sent by the client.
If the confirm is "Yes" the server deletes the requested directory and returns an acknowledgement to the client to indicate the success or failure of file deletion operation. (Directory must be empty in order for deletion to occur).
If the acknowledgement is positive, the client prints out "Directory deleted" and returns to "prompt user for operation" state.
If the acknowledgement is negative, the client prints out "Failed to delete directory" and returns to "prompt user for operation" state.
If the confirm is "No" the server returns to "wait for operation" state.
CD:
Client sends operation (CD) to change to a different directory on the server. Note: You can use CD followed by LS to verify that CD worked successfully.
Client sends the length of the directory name which will be sent (short int) followed by the directory name (character string).
Server receives the above information, decodes directory name size and directory name, and checks if the directory to be changed to exists or not.
If the directory exists, the server sends a positive confirm (integer value 1) back to the client if it successfully changed directories; otherwise, the server sends a negative confirm (integer value -1) back to the client.
If the directory does not exist, the server sends a negative confirm (integer value -2) back to the client.
Client receives the confirm from the server.
If the confirm is negative (-2), it prints out "The directory does not exist on server" and returns to "prompt user for operation/wait for operation" state.
If the confirm is negative (-1), it prints out "Error in changing directory" and returns to "prompt user for operation/wait for operation" state.
If the confirm is positive, the client prints out "Changed current directory" and returns to "prompt user for operation/wait for operation" state.
EXIT:
Client sends operation (EXIT) to exit.
Client closes socket, and exits.
Server closes socket and goes back to "wait for connection" state.
Client informs user that session has been closed.
Note: If it is not explicitly specified, the client and server will return to "prompt user for operation" and "wait for operation from client" state respectively after a successful operation and wait for the next operation.
Important Hint: When uploading and downloading large files, make sure to take into consideration the return value from reading the socket. The system may not provide the same number of bytes as you requested to fill the buffer!
General Notes
Your code may be written in C or C++. You should create two separate directories under the
dropbox/program2 directory, a server directory for the server code and a client directory for the
client code.
Each directory should contain a Makefile for building your code appropriately.
The request for a file is transmitted using a 16 bit value (short int - containing the length of the filename) followed by a string which contains the name of the file. When sending a file to the server you need to send a 16 bit value (short int) followed by the file name to the server.
Whenever you send a file (through UP or DL), calculate the MD5 hash on both the sending and receiving end. If the hashes match, then the file transferred successfully. In particular, the MD5 hash is to be calculated with the md5sum command line utility. The syntax is md5sum filename to obtain the hash as a string (in hex). You can find more information about MD5 Hash at the Wikipedia Link.
Don't forget that the Endian-ness matters. Use htons / ntohs in order to encode a 16 bit (short) value for transmission. Use htonl / ntohl for 32 bit (int) values.
You need to display the throughput for the file transfer. Throughput will be part of your grade. Most likely, you will want to use the high resolution _timeval_ struct which will allow you to keep track of accuracy at the microsecond level. The gettimeofday function will allow you to retrieve a timer accurate to microsecond levels.
To determine the size of files, you may want to use the fseek (or equivalent ifstream operation) function and/or the peek operation. For efficiency reasons you probably should not "roll your own".
When in doubt, add in extra printf or cout statements to assist with debugging. Make sure to add in a carriage return or do a flush on the I/O buffer to ensure that debug information is displayed before program crashes occur. Make sure to disable your debugging output before handing in the assignment.
You can connect back to localhost (127.0.0.1) which will allow you to test your code on the same machine where you have the server running. Create a separate ssh terminal session back to the server and then run your client code by connecting to localhost. But make sure you have tested your solution on two different student machines before submission.
We provided three files in /afs/nd.edu/coursefa.18/cse/cse30264.01/files/program2 which will be
used to test the DL and LS operation: LargeFile.mp4 (43 MB), MediumFile.pdf (762 KB), SmallFile.txt (2 KB). Do not copy the test files to your dropbox. If everyone copies the files to their dropbox, we
will run out of disk space! Instead, make a symbolic link from the files in
/afs/nd.edu/coursefa.18/cse/cse30264.01/files/program2 to your dropbox/program2/server
directory.
Server Side Design
The server is responsible for handling the connection request from a single client, processing the request,
then looping back to handle further requests. For this particular assignment, your code only needs to handle
one client at a time. The server binary should be named myftpd.
The server should listen on the specified port number [the port number assigned to any of
your group members] that is given by command line argument. Your server should bind to the port and then listen
for incoming client connections. You may decide if you would like to allow timeouts for better
responsiveness but any sort of a timeout is purely optional. You may want to allow for port reuse for
quicker recovery after a crash.
Once a new client request arrives, your server should use the accept function to create a new client socket.
Once the file has been transmitted, return to the state where your server is waiting for a new command.
Your server should be invoked as follows: ./myftpd [Port]
Client Side Design
The client is responsible for initiating a connection to a server. Once connected, the client code should
prompt the user for an operation (DL, UP, RM, LS, MKDIR, RMDIR, CD, EXIT), and should transmit the operation to the
server. Your client binary should be named myftp. Your client should be invoked as follows: ./myftp Server_Name [Port]
The first argument is the hostname of the server to connect to (this will depend on what machine you start
your server code on). The second argument is the port number.
Once a transfer completes successfully, you need to display the throughput and MD5 hash for the transfer. You should display
information similar to the following for each file transfer (DL/UP).