Understanding FTP

RFC959 specifies the protocol for file transfer and is downloadable from http://www.w3.org/Protocols/rfc959/A3_FTP_RFCs.html. This protocol defines how an FTP client application and an FTP server must communicate.

Just like any client-server application, an FTP server should be available all the time and a server does not know anything about its clients. It is always the client that initiates a connection with the server. Before any file transfer can happen, a client needs to connect to the FTP server and log in with a username and a password. Some FTP servers allow anyone to access some or all of their content by requesting them to log in using an anonymous account—in other words, by using "anonymous" as the username and their email address as the password.

In FTP, two connections need to be established between a client and an FTP server. The first connection, the control connection, remains open during the whole session and acts as the communication channel the client uses to send requests to the server and for the server to send responses to those requests. The second connection is the data connection used to transfer files and other data. This connection opens just before some data need to be transferred. The data connection closes right after the data transfer.

Typically, the "conversation" on the control channel after a connection is established goes like this:

1. Server: OK, you are now connected. Tell me what you want.

2. Client: I would like to log in. Here is my username: "James."

3. Server: Username received. Now, send me your password.

4. Client: My password is "s3m1c0nduct0r."

By sending the username and password, the client tries to log in. If the login fails, the server asks the client to send the password again. If it is successful, an FTP session starts and file transfer can begin. The server terminates the session if it does not hear anything from the client within some period of time, usually 900 seconds.

The client can start transferring files between itself and the server. Again, the "conversation" goes like the following:

1. Client: Please send me companySecret.doc.

2. Server: Here you go. I am sending it from port x.

The client then uses another socket instance and tries to connect to the IP address and port specified by the server. Once connected at this port, the server starts sending the file. When all the data is sent, the server automatically closes the data connection. Then the server uses the control channel to send the client the following message:

Server: Connection complete.

A data connection also opens when the client needs to transfer a file or when the server needs to send the list of files and subdirectories in the specified directory. What really happens is of course more technical than the previous description. However, you should have the general idea.

Using FTP Commands

In a conversation between an FTP client application and an FTP server, the client sends a series of FTP commands and the server replies to each command sent by the client. The next client operation is determined by the previous server's reply.

Table 5-1 describes the FTP command that a client application can send to the server.

Table 5-1: FTP Commands

COMMAND	TYPE	DESCRIPTION
USER	Access control	Sends the username to the server to log in. This is normally the first command sent by the client after a control connection is established.
PASS	Access control	Sends the user password to the server to log in. This is normally the command that must be sent immediately after the USER command is sent.
ACCT	Access control	Sends the user's account information. Some FTP servers may require the user's account information to log in, and some may not. If required, this command must be sent right after the server sends the response to the client's PASS command. This response also determines whether the ACCT command needs to be sent. If the server sends a 332 cod to the client's PASS command, the ACCT command must be sent.
CWD	Access control	Changes the server's working directory.
CDUP	Access control	Changes to the parent directory. This is a special case for the CWD command.
SMNT	Access control	Mounts a different file system data structure without altering the client's login or accounting information.
REIN	Access control	Terminates the client, flushing all input/output and account information. Upon receipt of this command, the server leaves the control connection open.
QUIT	Access control	Terminates the client and closes the control connection. If file transfer is in progress when this command is received, the connection remains open for the server to send the file transfer completion reply code. Afterward, the connection closes.
PORT	Transfer	Specifies the data port to be used in the data connection. This command is normally not necessary because there are defaults for both the user and server data ports.
PASV	Transfer	Asks the server to become passive—in other words, requests the server to listen on a data port and to wait for a connection rather than initiate one upon receipt of a file transfer command. The server replies by sending the host address and port number this server is listening on for the next file transfer.
TYPE	Transfer	Specifies the representation type—in other words, whether the representation is ASCII, EBCDIC, or Image (binary).
STRU	Transfer	Specifies the file structure.
MODE	Transfer	Specifies the transfer mode (Stream, Block, or Compressed). The default is Stream.
RETR	Service	Requests the transfer of the specified file from the server.
STOR	Service	Asks the server to accept a file from the client. If a file with the same name already exists in the working directory, the file will be overwritten.
STOU	Service	Similar to STOR, but the file is saved in a different name. The new filename is created in the current directory under a name unique to that directory.
APPE	Service	Asks the server to accept a file from the client. If a file with the same name already exists in the working directory, the transferred file will be appended to the existing file.
ALLO	Service	Requests the server to reserve sufficient storage to accommodate the new file to be transferred.
REST	Service	Restarts a new file transfer.
RNFR	Service	Specifies the name of the file to be renamed. This command must be followed immediately by the RNTO command.
RNTO	Service	Specifies the new name for the file to be renamed.
ABOR	Service	Aborts the previous FTP service command.
DELE	Service	Deletes the specified file.
RMD	Service	Removes directory.
MKD	Service	Makes a new directory
PWD	Service	Prints the working directory.
LIST	Service	Requests the list of files/subdirectories in the specified directory and information on each individual file/subdirectory such as file size, modified date, and so on.
NLST	Service	Requests the list of files/subdirectories in the specified directory without information about each individual file/subdirectory.
SITE	Service	Asks the server to provide services specific to its system that are essential to file transfer but not sufficiently universal to be included a command in the protocol.
SYST	Service	Inquires about the server's operating system.
STAT	Service	Inquires about the status of a file transfer.
HELP	Service	Requests some helpful information regarding the server's implementation status over the control connection to the client.
NOOP	Service	No operation.

You terminate each FTP command with a carriage-return line feed. For example, the following code connects to ftp.microsoft.com and sends the USER command indicating the username James:

 Private server As String = "ftp.microsoft.com" Private port As Integer = 21 Private userName As String = "James" Private controlSocket As Socket Try   controlSocket = New _     Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp)   controlSocket.Connect(New IPEndPoint(Dns.Resolve(server).AddressList(0), port))   If controlSocket.Connected Then     Console.WriteLine("Connected. Waiting for reply...")     Dim bytes(511) As Byte ' an array of 512 bytes     Dim receivedByteCount As Integer     ' receive the server's response on successful connect     receivedByteCount = controlSocket.Receive(bytes)     ' send the USER command     Dim command As String     command = "USER " & userName & ControlChars.CrLf     controlSocket.Send(Encoding.ASCII.GetBytes(command), command.Length, 0)   End If Catch End Try 

An FTP connection carries a two-way dialogue between the FTP server and the client application. The FTP server sends a reply to any command sent by the client. To understand how the conversation takes place, it is important to understand the server's replies.

Sending FTP Replies

An FTP server replies to every FTP command from a client. These replies ensure that requests and actions are synchronized during the process of file transfer. They are also useful so that the client always know the state of the server.

An FTP command generates one or more replies. For example, a USER command makes the server send a reply requesting the client to send the PASS command. Some commands generate more replies. An example of multiple replies is when an FTP server is about to send a file to a client. First, the server sends a reply notifying the client that the file transfer process will commence. After the file transfer finishes and the data connection closes, the server sends the second reply telling the client that the file transfer has completed.

An FTP reply consists of a reply code followed by a space and some description. A reply code is always a three-digit number specified in RFC959, but the descriptions can be different from one server implementation to another. An FTP client should only rely on the reply code.

Each of the three digits in a reply code has special meaning. The first digit is the most important and indicates whether the FTP command is successful, has failed, or is incomplete. There are five possible values for the first digit in the reply code: 1, 2, 3, 4, and 5.

Table 5-2 describes the meaning of each possible value of the first digit in a reply code.

Table 5-2: The First Digit in an FTP Reply

VALUE	DESCRIPTION
1	Positive preliminary reply. The requested action is being initiated; expect another reply before proceeding with a new command. This type of reply indicates that the command was accepted and the client may now pay attention to the data connections for implementations where simultaneous monitoring is difficult.
2	Positive completion reply. The requested action has been successfully completed. A new request may be initiated.
3	Positive intermediate reply. The command has been accepted, but the requested action will not be active, pending receipt of further information. The user should send another command specifying this information.
4	Transient negative completion reply. The command was not accepted and the requested action did not take place, but the error condition is temporary and the action may be requested again. The user should return to the beginning of the command sequence, if any. Note that it is difficult to assign a meaning to transient, particularly when two distinct sites (server and client) have to agree on the interpretation.
5	Permanent negative completion reply. The command was not accepted and the requested action did not take place. The client is discouraged from repeating the exact request (in the same sequence).

Table 5-3 describes the meaning of each possible value of the second digit in a reply code.

Table 5-3: The Second Digit in an FTP Reply

VALUE	DESCRIPTION
0	These replies refer to syntax errors, syntactically correct commands that do not fit any functional category, and unimplemented or superfluous commands.
1	These are replies to requests for information, such as status or help.
2	These replies refer to the control and data connections.
3	Authentication and accounting. These are replies for the login process and accounting procedures.
4	Unspecified yet.
5	These replies indicate the status of the server file system vis- -vis the requested transfer or other file system action.

The third digit of the reply code gives a finer gradation of the meaning indicated by the second digit. Table 5-4 should make it clearer.

Table 5-4: FTP Reply Codes in Numerical Order

VALUE	DESCRIPTION
110	Restart marker reply.
120	Service ready in nnn minutes.
125	Data connection already open; transfer starting.
150	File status OK; about to open data connection.
200	Command OK.
202	Command not implemented, superfluous at this site.
211	System status, or system help reply.
212	Directory status.
213	File status.
214	Help message.
215	NAME system type, where NAME is an official system name from the list in the Assigned Numbers document.
220	Service ready for new user.
221	Service closing control connection.
225	Data connection open; no transfer in progress.
226	Closing data connection. Request file action successful (for example, file transfer or file abort).
227	Entering Passive Mode (h1, h2, h3, h4, p1, p2).
230	User logged in; proceed.
250	Requested file action OK, completed.
257	"PATHNAME" created.
331	Username OK; need password.
332	Need account for login.
350	Requested file action pending further information.
421	Service not available, closing control connection. This may be a reply to any command if the service knows it must shut down.
425	Cannot open data connection.
426	Connection closed; transfer aborted.
450	Requested file action not taken. File unavailable (for example, file busy).
451	Requested action aborted: local error in processing.
452	Requested action not taken. Insufficient storage space in system.
500	Syntax error, command unrecognized. This may include errors such as command line too long.
501	Syntax error in parameters or arguments.
502	Command not implemented.
503	Bad sequence of commands.
504	Command not implemented for that parameter.
530	Not logged in.
531	Need account for storing files.
550	Requested action not taken. File unavailable (for example, file not found, no access).
551	Requested action aborted: page type unknown.
552	Requested file action aborted. Exceeded storage allocation (for current directory or dataset).
553	Requested action not taken. Filename not allowed.

Usually, the description in a reply code is one line long. There are cases, however, where the text is longer than a single line. In these cases the complete text must be bracketed so the client application knows when it should stop reading the reply. This requires a special format on the first line to indicate that more than one line is coming, and another on the last line to designate it as the last. At least one of these lines must contain the appropriate reply code to indicate the state of the transaction. The RFC959 decides that both the first and last line codes should be the same in the case of multiline reply description.

For example, replying to a PASS command, an FTP server may send the single-line reply:

 230 User logged in. 

Another FTP server may send the following multiline reply:

 230-User logged in. Welcome to the Atlantis Research Center. Please note that access to this site is restricted to authorized people only. This site is closely monitored 24 hours a day. 230 Please proceed.