Objective This assignment asks you to implement a popular application layer protocol. The idea is for you to be able to interpret and implement the specifications of an RFC and identify the significance of the different states the protocol transits through as the task being achieved by the protocol is being performed. RFCs are definitions of protocols that all clients and servers must follow. You will be writing a client which is to interact with a server which has already been written to adhere to the protocol. Problem In this assignment, you are to implement a FTP (File Transfer Protocol) client that can login, list directory information, and store and retrieve information from a server hosting the FTP service. You are to write the client code in C, C++, Java or Python ONLY. Other languages MUST BE APPROVED by the Professor before implementation. Any questions – ASK! Libraries such as the libnsl, libresolv, and libsocket with C/C++ and the package java.net, and the socket Python library are the ONLY permissible libraries that you can use for socket programming. In case you do want to use some other library, CONFIRM WITH THE PROFESSOR FIRST. Using other libraries without permission will cause a significant loss of points on the assignment (for example – you must write the logging yourself, not use a library). This is to assure that you get the right goals out of the assignment. It is your responsibility to ensure that the code runs on tux.cs.drexel.edu or a suitable environment (like eclipse, java, Microsoft Studio Code or something similar). Code that doesn’t compile/run will be graded as a zero. ALL source code must be available for inspection as well as any makefiles/build scripts. You must also specify where the program will run (tux, etc.). We will verify that all program work. Please consult the syllabus about plagiarism. You must write the code from scratch. You may not “port” other code that you find on the Internet. If we find the code that you use, you will get a zero on the assignment (and possible other penalties). IF YOU CAN FIND IT, SO CAN WE. Input / Command Line The client program should accept the following command line arguments: The first argument is a REQUIRED argument and is the name of the FTP server host (or IP address). If a hostname (non-numeric) is entered, it should be translated into the appropriate IP address via a call to a DNS resolver. The second argument is a REQUIRED argument and is the filename that logs all the messages generated by the client and received from the server. Each message is to be logged in a single line. The message should include a full timestamp and the data sent or received. Data transfers do not have to be logged (but it would be nice and helpful for debugging), but some indication of the data transfer should be logged (opening and closing port). This file should be appended to with each run of the client (not overwritten). A sample log file could look like: 01/18/2021 22:00:00.0002 Connecting to tux.cs.drexel.edu (129.25.8.226). 01/18/2021 22:00:00.0011 Received: 220 FTP Server ready. 01/18/2021 22:00:00.0031 Sent: USER cs472 01/18/2021 22:00:01.0099 Received: 331 Username received, please send the Password. The last command line argument is optional, and if specified, denotes the port number to connect to other than the default. If not specified, the default port number of 21 should be used. A sample command line would be: ftpclient 10.246.251.93 mylog.txt This would run the ftpclient connection to 10.246.251.93 at port 21. Another sample command line would be: Ftpclient tux.cs.drexel.edu mylog.txt 2121 This would run the ftpclient connecting to tux.cs.drexel.edu at port 2121 rather than port 21 (assuming that there was a FTP server running there) – the goal is to make the client more flexible as to what it connects to for a later assignment. Protocol details Refer to RFC 959 (https://www.rfc-editor.org/rfc/pdfrfc/rfc959.txt.pdf) for protocol messages and semantics. Refer to RFC 2428 (https://www.rfc-editor.org/rfc/pdfrfc/rfc2428.txt.pdf) for details about EPRT and EPSV command details. Your client should implement the following features: It must parse the command line and check all parameters. It must set up an appropriate connection with the server. Correctly handle ALL error conditions, non-supported commands, and cases like unreachable servers and errors in the client. You MUST use try/catch blocks to ensure correct operations. (faulting is a big problem). Your client need only implement the following commands (and any responses that these commands generate): USER, PASS, CWD, QUIT, PASV, EPSV, PORT, EPRT, RETR, STOR, PWD, SYST, LIST, HELP. NOTE: The Drexel cloud does not support IPV6, so with EPRT/EPSV, you can only test with the IPV4 versions. When the client initiates, it should ask the user for his usercode and password and send those to the server (via the USER and PASS commands). If any errors are found, they should be noted and the client should terminate. If successful, a prompt should be shown which allows the other commands to be entered. The commands PASV/EPSV and PORT/EPRT and RETR are used for retrieving files. PASV/EPSV and PORT/EPRT and STOR are used for storing files. FTP uses a separate data connection to transfer files. You’ll be telling the FTP server to use another port and then connect to that and send the RETR command to get the data or STOR to put the data. The data will go through the other connection. The client executes until the user wants to stop and the program sends the QUIT command. Your client MUST handle ALL errors returned from these commands and generate the appropriate error text to the local screen. Your client must not fail, more than “just work”. Segmentation faults are a BAD thing. IMPORTANT: The user interface is up to you, but similarity to the current FTP client would be easy to understand. I DO NOT want the user to be entering the actual FTP commands, so I’d like to you have a simple UI (it doesn’t have to be graphical) and the program constructing/deconstructing the FTP commands/responses (think about question 5 from the first homework). Look at what the current ftp client does for an idea of what you should be doing. For example, on Windows or Linux machines, go to a command line and type ftp and look at what it does. Appropriate Commenting Commenting is an important part of programming for understanding the code, both now and later. Each source module should have a header describing the author and goal of the module. For example: /* * CS472 – Homework #2 * Mike Kain * main.c * * This module is the major module of the ftp client, with the main processing loop. */ Each procedure should have a short header to denote what it provides to the overall program. /* * main() * The main programming loop of the FTP client. It initiates the TCP socket and begins the * conversation to the FTP server. */ Each block of code should have a comment to denote what it does. If it was tough to figure out, you should add more details about why for later. This helps with supportability of your code. /* * Connect to the server at the address that was specified in the command line. */ Testing There is a cloud instance for use for students who do not have access to another FTP server. The IP address (only visible from within the Drexel network) is 10.246.251.93 The usercode is cs472 The password is hw2ftp NOTE: You can use this instance for debugging, but you can also use any FTP server. You can even host you own (the cloud server is running vsftpd). Questions to be answered and turned in with the project. 1. Think about the conversation of FTP – how does each side validate the other (on the connection and data ports – think of each separately)? How do they trust that they’re getting a connection from the right person? 2. How does your client know that it’s sending the right commands in the right order? How does it know the server is trustworthy? Your submission Your submission MUST contain the following: Well documented code (VERY, VERY, VERY WELL documented code) that should compile correctly. See above rules. A Readme.txt file detailing instructions to compile your code or the use of your makefile and how to run your code. A Sample run and results (log files, etc.) – look at the script command in Linux. Answers to the questions above. Any other information you deem important (like your name, etc.) Point sheet Points below are for the maximum for the concept – given to an EXCELLENT implementation. Command line processing 5 points Connection with server 5 points PDU delineation 5 points Simple commands & responses (2 pts @) 16 points USER, PASS, CWD, QUIT, PWD, SYST, LIST, HELP Data transfer commands & responses (5@) 30 points PASV, EPSV, PORT, EPRT, RETR, STOR All errors handled correctly 5 points Well documented code 10 points Readme included 3 points Sample run and results 3 points Logging implemented and submitted 8 points Questions (5@) 10 points Total: 100 points