Fall 2019 CSE30264 Programming Assignment 2 - File Transfer Protocol (FTP)
Total Points: 100 points
Goal: Program a Prototype of a FTP application using TCP
Assigned: September 23, 2019
Due: October 9, 2019 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, creating an empty 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 document. Note: please refer to appendix A for the port number assigned to you (the same as PG1).
Protocol - Simple File Transfer
Server opens the 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.
DNLD: Note: Please test DNLD with the three test files (i.e., LargeFile.mp4, MediumFile.pdf, SmallFile.txt) discussed in the general notes.
Client sends operation (DNLD) to download a file from the server.
Client sends the length of the filename (short int) followed by the filename (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 integer in another message.
If the file does not exist, server will return a negative confirmation (32-bit integer value -1). After that, the server should return to the "wait for operation from client" state.
Client receives the 32-bit file length from server.
Client should decode the 32-bit value.
If the value is -1, 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 -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 "filename"
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.
UPLD:
Client sends operation (UPLD) to upload a local file to a server.
Client sends the length of the filename which will be sent (short int) followed by the filename (character string). Note: you can create a local file called "upload.txt" with random strings to test the UPLD operation.
Server receives the above information, decodes filename size and filename, 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.
CRFL:
Client sends operation (CRFL) to create an empty file on the server.
Client sends the length of the filename which will be sent (short int) followed by the filename (character string).
Server receives the above information, decodes filename size and filename, and checks to see if the file exists in its local directory.
If the file does not exist:
Server creates an empty file with the decoded filename.
Serve also sends a positive confirmation (integer value 1) to the client and returns to the "wait for operation from client" state.
If the file already exists, server will return a negative confirmation (integer value -1). After that, the server should return to the "wait for operation from client" state.
Client receives the confirmation from the server.
If the confirmation is positive, it prints out "The file was successfully created" and returns to
"prompt user for operation" state.
If the confirmation is negative, it prints out "The file already exists" and returns to
"prompt user for operation" state.
RMFL:
Client sends operation (RMFL) to delete a file from the server. Note: you can create a test file called "delete.txt" in the server directory using CRFL to test the RMFL operation.
Client sends the length of the filename which will be sent (short int) followed by the filename (character string).
Server receives the above information, decodes filename size and filename, and checks if the file to be deleted exists or not.
If the file exists, the server sends a positive confirmation (integer value 1) back to the client.
If the file does not exit, the server sends a negative confirmation (integer value -1) back to the
client.
Client receives the confirmation from the server.
If the confirmation is negative, it prints out "The file does not exist on server" and returns to
"prompt user for operation" state.
If the confirmation 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 confirmation (i.e., "Yes" or
"No") back to the server.
If the user's confirmation is "Yes", the client waits for the server to send the confirmation of file
deletion.
If the user's confirmation 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 confirmation sent by the client.
If the confirmation is "Yes", the server deletes the requested file and returns an acknowledgment to the client to indicate the success or failure of file deletion operation.
If the confirmation is "No", the server returns to "wait for operation from client" state.
LIST:
Client sends operation (LIST) 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 integer.
Client receives the size, and goes into a loop to read directory listing.
Once the listing is received, client displays the listing to user.
Client and server return to "prompt user for operation" and "wait for operation from client" state respectively.
MKDR:
Client sends operation (MKDR) to make a directory on 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 confirmation (integer value -2) back to the client.
If the directory does not exit, the server sends a positive confirmation (integer value 1) back to the client if the directory is successfully created; otherwise, the server sends a negative confirmation (integer value -1) back to the client.
Client receives the confirmation from the server.
If the confirmation 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 confirmation is negative (-1), it prints out "Error in making directory" and returns to "prompt user for operation/wait for operation" state.
If the confirmation is positive, the client prints out "The directory was successfully made" and returns to "prompt user for operation/wait for operation" state.
RMDR:
Client sends operation (RMDR) to remove a directory on the server. Note: Directory must be empty for RMDR 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 confirmation (integer value 1) back to the client.
If the directory does not exit, the server sends a negative confirmation (integer value -1) back to the client.
If the directory exists and is not empty, the server sends a negative confirmation (integer value -2) back to the client.
Client receives the confirmation from the server.
If the confirmation 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 confirmation is negative (-2), it prints out "The directory is not empty" and returns to "prompt user for operation/wait for operation" state.
If the confirmation 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 confirmation (i.e., "Yes" or "No") back to the server.
If the user's confirmation is "Yes" the client waits for the server to send the confirmation of directory deletion.
If the user's confirmation 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 confirmation sent by the client.
If the confirmation is "Yes" the server deletes the requested directory and returns an acknowledgment 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 acknowledgment is positive, the client prints out "Directory deleted" and returns to "prompt user for operation" state.
If the acknowledgment is negative, the client prints out "Failed to delete directory" and returns to "prompt user for operation" state.
If the confirmation is "No" the server returns to "wait for operation" state.
CHDR:
Client sends operation (CHDR) to change to a different directory on the server. Note: You can use CHDR followed by LIST to verify that CHDR 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 confirmation (integer value 1) back to the client if it successfully changed directories; otherwise, the server sends a negative confirmation (integer value -1) back to the client.
If the directory does not exist, the server sends a negative confirmation (integer value -2) back to the client.
Client receives the confirmation from the server.
If the confirmation 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 confirmation is negative (-1), it prints out "Error in changing directory" and returns to "prompt user for operation/wait for operation" state.
If the confirmation is positive, the client prints out "Changed current directory" and returns to "prompt user for operation/wait for operation" state.
QUIT:
Client sends operation (QUIT) to exit.
Client closes the socket, and exits.
Server closes the socket and goes back to the "wait for connection" state.
Client informs user that the 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
/escnfs/courses/fa19-cse-30264.01/dropbox/yournetid/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 filename to the server.
Whenever you send a file (through UPLD or DNLD), 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 /escnfs/courses/fa19-cse-30264.01/files/program2/, which will be
used to test the DNLD and LIST operation: LargeFile.mp4 (43 MB), MediumFile.pdf (762 KB), SmallFile.txt (1.2 KB).
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 (DNLD, UPLD, CRFL, RMFL, LIST, MKDR, RMDR, CHDR, QUIT), 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 (DNLD/UPLD).
Submit a gzipped tar file of your entire assignment package to the /escnfs/courses/fa19-cse-30264.01/dropbox/yournetid/program2 directory. The
archive must include the following:
Working client code in a client subdirectory
Makefile for the client.
Source file for the client.
Appropriate comments and your name.
Working server code in a server subdirectory
Makefile for the server.
Source file for the server
Appropriate comments and your name.
README file
Listing of the included filenames and example commands to run your code in the archive.
Evaluation Rubric
Client code (40 pts total)
[5 pts] Included Makefile and code compiles without errors.
[5 pts] Code performs the DNLD operation correctly.
[5 pts] Code performs the UPLD operation correctly.
[5 pts] Code performs the RMFL operation correctly.
[3 pts] Code performs the CRFL, MKDR, RMDR, and CHDR operations correctly.
[2 pts] Code performs the LIST and QUIT operations correctly.
[4 pts] Code provides reasonable error checking.
[4 pts] Reasonable code performance (block transfers vs. single byte transfers).
[4 pts] Code is commented with appropriate header information.
Server code (40 pts total)
[5 pts] Included Makefile and code compiles without errors.
[5 pts] Code performs the DNLD operation correctly.
[5 pts] Code performs the UPLD operation correctly.
[5 pts] Code performs the RMFL operation correctly.
[3 pts] Code performs the CRFL, MKDR, RMDR, and CHDR operations correctly.
[2 pts] Code performs the LIST and QUIT operations correctly.