The project requires a significant amount of work on research, design and implementation. It is advised that you should start the project as soon as possible.

A Simple File Transfer Protocol

Design and implement a simple network protocol that can be used to download files from a remote site and to upload files to a remote site, and a client and a server programs that communicate using that protocol. The protocol should use TCP as its transport layer protocol. The server must be able to serve multiple client requests simultaneously. For simplicity, do not consider any authentication process in this project, hence the server will provide its service to any client with the right site address and port number.

To simplify project marking, please name your server program myftpd with the following command line syntax (here the letter d in myftpd stands for daemon, since the server should run as a daemon process:

myftpd [ initial_current_directory ]

The server process maintains a current directory. Its initial value should be the one inherited from its parent process unless the optional
initial_current_directory

is given. In the latter case, the user supplied path should be used to set the initial current directory of the server. This can be done

using the function chdir. A client can use the cd command to change the (child) server's current directory later.

The client program should be named myftp with the following command line syntax:

myftp [ hostname | IP_address ]

where the optional hostname (IP_address) is the name (address) of the remote host that provides the myftp service. If the hostname or IP_address is omitted, the local host is assumed.

After the connection between the client and the server is established, the client should display a prompt > and wait for one of the following commands:

- pwd - to display the current directory of the server that is serving the client;
- lpwd - to display the current directory of the client;
- dir - to display the file names under the current directory of the server that is serving the client;
- ldir - to display the file names under the current directory of the client;
- cddirectory_pathname - to change the current directory of the server that is serving the client; Must support "." and ".." notations.
- lcddirectory_pathname - to change the current directory of the client; Must support "." and ".." notations.
- get filename - to download the named file from the current directory of the remote server and save it in the current directory of the client;
- put filename - to upload the named file from the current directory of the client to the current directory of the remove server.
- quit - to terminate the myftp session.

The myftp client should repeatedly display the prompt and wait for a command until the quit command is entered.

This project consists of three components:

1. Protocol Specification:

You must specify a protocol for communication between the myftp client and the myftp server. This protocol will become the sole reference to which the client program and the server program can be separately implemented. This means that, by referring to the protocol, the client and server can be implemented independent of each other. The design and implementation of the client (server) should not depend on (1) what strategy and algorithms were used to implement the server (client), (2) what programming language were used to implement the server (client), and (3) what operating system the server (client) is running on. The protocol must be complete, i.e., it contains all the necessary information required by both parties to communicate, such as the format and sequence of data exchanges between the client and the server, the transport layer protocol (TCP or UDP) used to deliver the data, and the server port number. However it should not contain anything that unnecessarily constrains the implementation of the client or the server. For example, there is no point to limit the implementation language to a particular programming language in the protocol, or to require the client or the server to be implemented with a particular data structure.

Before you attempt this project, you should first complete the first two exercises in Lab 11. You may also read the Trivial FTP Protocol given in Appendix 17A of the textbook (Stallings: Chapter 17 of Online Chapters). Note TFTP uses UDP, while myftp protocol must use TCP.

2. Client Program:

You need to implement a client program according to the myftp protocol. Note that the client should never rely on any undocumented internal tricks in the server implementation. Apart from the myftp protocol, you should not make any other assumption about the server program in your client program.

3. Server Program:

You need to implement a server program according to the myftp protocol. Note that the server should never rely on any undocumented internal tricks in the client implementation. Apart from the myftp protocol, you should not make any other assumption about the client program in your server program.

Note the following additional requirements/explanations:

- The name of the client executable program must be myftp. The name of the server executable program must be myftpd.
- To avoid potential conflict in the use of the server's ``well known'' port number when several students use the ceto server, you should use the TCP port allocated to you as the default server listening port.

- Tests should show the cases where both the client and the server are on the same machine as well as on different machines (you may want to use ceto.murdoch.edu.au to do the testing, however you must kill your server at the end of the test). They should also show that more than one client can obtain the service at the same time. You may use the command script to record the terminal I/O. When debugging your network program on a standalone machine (e.g., on your home Linux), you may use localhost as the ``remote'' host name.

- Tests should show that the program can transfer not only small files (e.g., 0, 10 and 100 bytes) but also large files (at least several mega bytes), and not only text files but also binary files. In addition, you must show that the transferred file and the original file are identical not only in their sizes but also in their contents (use diff command).

- The specification of the protocol is an important part of this question. Please provide a full specification of the protocol in a section separated from the client and server implementations. You should complete this specification before starting the implementation of the client and server programs.

- Please note that the server must be implemented as a daemon and must log all of its interactions with the clients.

Documentation Requirements

Your assignment must be submitted in the form of a single tar archive file (or a ZIP file) via the Unit LMS.

Your tar archive must contain the following files:
- One Microsoft Word document named "Assignment2.docx". This file replaces the hard-copy submission that is required in the traditional non-electronic submissions. See the detailed requirements of this file later in this section.

- All your C/C++source code, makefiles used to compile source code and to build the executable programs, Linux executable programs, test files, test output files, etc, that are related to your project.

You can create test output files by cut-and-pasting from your terminal output into a text file. Alternatively you may use command script to record terminal input and output (but you need to remove the control characters). Please do not modify the test output.

You must make sure that your program can be compiled and run in other machines. Do not use any non-standard feature or any feature that is only available in your machine. Do not hard code any directory path into your program otherwise your program may not run on someone else's machine.

The file "Assignment2.docx"

This Word file should contain the documents in the following order:

1. Assignment Check List:
all students (internal and external) must complete ICT310 Major Assignment Two Check List and this check list and include it in your Word file.

2. Extension Granted:
If you have been granted an extension, include the email from your Unit Coordinator after the declaration form. The extension does not count unless it is documented here.

3. List of Files:
List the name and purpose of each file included in the tar archive.

4. The project title and a brief description of the project:
You can cut-and-paste the project question from this web page to your Word file.

5. Self diagnosis and evaluation:
Provide a statement giving
a. a list of features that are fully functional.
b. a list of features that are not fully functional (include features that are not fully implemented, or not implemented at all).
This statement is important and essential. There will be a heavy penalty (>50%) if this statement is too vague, short of details and/or misleading.

6. Discussion of your solution:
In particular, you should emphasise any aspect of your solution that is novel or unusual, such as use of particular data structure or algorithm. You should also discuss technical choices available to you, the consideration behind your technical choice, and whether the result of your solution meets your expectation. You should highlight the strength and weakness of your solution and point out what improvement can be made to your solution.

7. Protocol (Project 2 and Project 3 only):
For Project 2 (A Simple File Transfer Protocol), you must include your protocol specification here. For Project 3 (A Simple HTTP Client and a Simple HTTP Server), you must include your essay explaining your understanding of the HTTP protocol here.

8. Test evidence:
When testing your program, you should turn on gcc warnings (gcc -Wall ...) and fix all warnings before submitting your program.
You must provide sufficient number of test cases to demonstrate and convince your tutor that your project has met all requirements.
For each test case, you should 1) explain the purpose of the test, 2) provide the test output including the command line used, and 3) give an explanation on what the test has achieved based on the test results.

It is important that you present a sufficient number of test cases to convince your tutor that your solution works in all situations. Please note that although your tutor may test your program to verify the evidence presented in your documentation, it is not the responsibility of your tutor to test your program for the purpose of finding marks for you. It is up to individual student to mount a convincing case that the submitted solution works as required. You will be awarded marks based on the test evicence you have presented. Therefore if you do not provide test evidence you do not get marks regardless of whether your program works or not, or if the test evidence you have provided is not sufficient, your marks will be substantially reduced.

You should format your test output using fonts such as courier so that test output is clearly distinguishable from the rest of the document. You should not modify the test output unless it is too long and repetitive.

In presenting your test cases, do not use the tabular format that you may have been told to use in some other units. Simply present one test case after the other in a linear order.

9. Source code listing:
The source code must be properly indented, commented, and formatted. The source code included in this Word file must be identical to that of source code files included in the tar archive.

You must also include the makefile for building your program.

Your tutor may mark your project directly on your Word file. The marked project and comments will be returned to you via Unit LMS.
The documentation requirements, as described above, will be strictly enforced. Your project will not be marked, or your marks will be significantly reduced, if you fail to adhere to the above requirements.

Policy on the Reuse of the Third Party Source Code

Please read this section very carefully.

All students are encouraged to solve the problems independently with their own source code. I understand, however, that occasionally there may be justifiable reasons to re-use source code from a third party. Please note that if you have used one or more pieces of third party source code in your program (this includes the situations where you have made minor modifications to the third party source code), your project will be acceptable only if you have satisfied all of the following conditions:

- The third party source code is fully identified, including the page numbers and line numbers in your hard-copy project documentation, and

- The origin of the third party code is fully disclosed and acknowledged in your project submission, and

- The third party source code is fully commented in your program listing. All variables, functions and major control structures must be commented to show clearly that you understand the logic of the code, and

- The third party source code is less than 20% of your program (in terms of the number of lines), excluding the code specifically allowed to be used.

Failure to satisfy any one of the above conditions will result in 0 marks being awarded to your entire project.

The above policy will be rigorously enforced by the Unit Coordinator and Tutors.

Grievance with Assignment Marking

Once you have received your marked assignment, if you have any grievance with the marking, you must raise it with your Unit Coordinator by email, within 10 days of returning of your marked assignment to the Unit LMS, or within the announced deadline in the Unit LMS, whichever is earlier. Otherwise the marks awarded to you will be final and will be used to calculate your final weighted average score for the unit.

In presenting your work, you must document the test cases and test outputs for each feature required by the project. The test output can be in the form of terminal output. You may copy the text from the terminal output and paste it to your Word document (always include the command line). You should format the terminal output using a monospaced font so that it is clearly distinguishable from the rest of texts in your document. It is even better if you place the terminal output in a text box so that it is clearly separated from other texts in your document. But do not modify your test output unless it is too long and repetitive - heavy penalties will be applied if test output is modified to make your work appear better than what it really is!

Marking will be based on the number of working features demonstrated in your documentation. If a feature works and you have provided test evidence that the feature works in the form of test cases and test outputs, and your explanation of the test is convincing, you will get the marks allocated to the feature. Otherwise you will not get marks for that feature even if you have implemented it.

Read Documentation Requirements for further and more detailed requirements regarding the test documentation.