Description
1 Introduction
In this assignment, we will implement a multi-client file transfer application called MYFTP. MYFTP
is a simplified version of the File Transfer Protocol (FTP). It includes the basic functionalities of FTP,
such as file upload/download and file listing. It also enables multiple clients to simultaneously connect
to the server at the same time. Our objective is to develop hands-on skills of socket programming and
multi-threaded programming in C/C++.
2 Protocol Description
2.1 Overview
MYFTP is mainly composed of two entities: client and server. As their names suggest, the server hosts
a file repository where the client can request to upload or download files.
MYFTP supports three main functions: (i) list the files that are stored on the server, (ii) upload files
from the client to the server, or (iii) download files from the server to the client.
2.2 Protocol Messages
The client and the server will exchange protocol messages in order to perform the functions. All protocol
messages are preceded with the protocol header shown below:
struct message_s {
unsigned char protocol[5]; /* protocol string (5 bytes) *
unsigned char type; /* type (1 byte) */
unsigned int length; /* length (header + payload) (4 bytes) */
} __attribute__ ((packed));
The protocol field is always set to be the string that starts with the string “fubar”. The type field
has different possible values as specified in Section 2.3. The length field is the length of the message
(including the header and payload) to be sent over the network. The size of the payload is a variable
depending on the message type. You can safely assume that the length is no larger than 2
32 − 1.
We add attribute ((packed)) to avoid data structure alignment and pack all variables
together without any gap1
. Defining a packed structure makes our life easier when we calculate the size
of a message to be sent over the network.
2.3 Protocol Details
We now explain the functions that MYFTP supports. We also introduce the protocol messages that
accompany each function, as well as the formats of the protocol messages. For now, let us assume that
there is only one single client. Table 1 lists all protocol messages that are used.
1See http://en.wikipedia.org/wiki/Data_structure_alignment for details
1
LIST REQUEST protocol fubar
type 0xA1
length header length
LIST REPLY protocol fubar
type 0xA2
length header length + payload length
payload file names, in null-terminated string
GET REQUEST protocol fubar
type 0xB1
length header length + payload length
payload file name, in null-terminated string
GET REPLY protocol fubar
type 0xB2 or 0xB3
length header length
PUT REQUEST protocol fubar
type 0xC1
length header length + payload length
payload file name, in null-terminated string
PUT REPLY protocol fubar
type 0xC2
length header length
FILE DATA protocol fubar
type 0xFF
length header length + file size
payload file payload
Table 1: Protocol messages
2.3.1 List Files
Suppose that the client wants to list all files that are stored in the server. The client will issue a command
list. Then it will send a protocol message LIST REQUEST to the server. The server will reply a
protocol message LIST REPLY, together with the list of available files.
All files are stored in a repository directory called data/, which is located under the working directory of the server program. We assume that the directory has been created before the server starts. To
list files in a directory, you may use the function readdir() (use man readdir to see its usage).
All file names are delimited by the newline character ‘\n’.
2.3.2 File Download
Suppose that the client wants to download a file from the server. The client will issue a command
get FILE, where FILE is the name of the file to be downloaded. It first sends a protocol message
GET REQUEST to the server. The server will reply a protocol message GET REPLY with the type
field set to 0xB2 if the file exists or 0xB3 otherwise. If the file exists, the server will send a FILE DATA
message that contains the file content following the GET REPLY message.
Note that a file can be in either ASCII or binary mode. You should make sure that both ASCII and
binary files are supported. Here, we assume that the file size is at most 1 GiB (which is equal to 2
30
bytes).
2.3.3 File Upload
Suppose that the client wants to upload a file to the server. The client will issue a command put FILE,
where FILE is the name of the file to be uploaded. First, the client will check whether the file exists
locally. If not, the client will display an error message saying the file doesn’t exist. If the file exists,
then the client will send a protocol message PUT REQUEST to the server. The server will reply a
protocol message PUT REPLY and awaits the file. Then the client will send a FILE DATA message
2
that contains the file content (we use the same FILE DATA message as in file download).
Here, we assume that the file to be uploaded resides in the same working directory as the client
program. If the server has already stored the file before, the file will be overwritten. Note again that all
files are in ASCII or binary mode. We again assume that the file size is at most 1 GiB.
2.4 Interfaces
The server uses the following command-line interface:
sparc1> ./myftpserver PORT_NUMBER
You may fill in the port number as desired. The client uses the following command-line interface:
client> ./myftpclient <list|get|put>
Note that the file argument only exists for the get and put commands. You may define your own
output format for any error message.
2.5 Implementation Issues
The client and the server can reside in different machines with different operating systems (e.g., Linux
vs. Unix), and all functions should remain correct. Make sure all byte ordering issues are properly
addressed (see Tutorial notes).
The server may support multiple clients that may upload or download files simultaneously. We assume
that no two clients will upload or download a file with the same file name simultaneously (to make your
life easier), but it is possible that a client downloads a file that is previously uploaded by another client.
3 Milestones
Your implementation should have the following functions:
• The client can list files in the repository directory of the server.
• The client can download a file (either an ASCII or binary file) from the server. If the file doesn’t
exist, the server replies with an error message.
• The client can upload a file (either an ASCII or binary file) to the server. If the file doesn’t exist
locally, the client displays an error message.
• The client and the server can reside in different machines with different operating systems.
• Now the server needs to support a general number N of active connections (assume that N ≤ 10).
You will have to implement a multi-client version using multi-threading based on the pthread
library.
Aside the above functions, you may make assumptions to address the features that are not mentioned
in this specification.
4 Submission Guidelines
You must at least submit the following files, although you may submit additional files that are needed:
• myftp.h: the header file that includes all definitions shared by the client and the server (e.g., the
message header)
• myftp.c: the implementation of common functions shared by both the client and the server
• myftpclient.c: the client program
3
• myftpserver.c: the server program
• Makefile: a makefile to compile both client and server programs
• Declaration form for group projects:
(http://www.cuhk.edu.hk/policy/academichonesty/Eng_htm_files_(2013-14)
/p10.htm)
Your programs must be implemented in C/C++. They must be compilable on Unix/Linux machines in
the department. Please refer to the course website for the submission instructions. We will arrange demo
sessions to grade your assignments. Have fun! 🙂
4
