27.2 FTP Protocol

27.2 FTP Protocol

FTP differs from the other applications that we've described because it uses two TCP connections to transfer a file.

  1. The control connection is established in the normal client “server fashion. The server does a passive open on the well-known port for FTP (21) and waits for a client connection. The client does an active open to TCP port 21 to establish the control connection. The control connection stays up for the entire time that the client communicates with this server. This connection is used for commands from the client to the server and for the server's replies.

    The IP type-of-service for the control connection should be "minimize delay" since the commands are normally typed by a human user (Figure 3.2).

  2. A data connection is created each time a file is transferred between the client and server. (It is also created at other times, as we'll see later.)

    The IP type-of-service for the data connection should be "maximize throughput" since this connection is for file transfer.

Figure 27.1 shows the arrangement of the client and server and the two connections between them.

Figure 27.1. Processes involved in file transfer.
graphics/27fig01.gif

This figure shows that the interactive user normally doesn't deal with the commands and replies that are exchanged across the control connection. Those details are left to the two protocol interpreters. The box labeled "user interface" presents whatever type of interface is desired to the interactive user (full-screen menu selection, line-at-a-time commands, etc.) and converts these into FTP commands that are sent across the control connection. Similarly the replies returned by the server across the control connection can be converted to any format to present to the interactive user.

This figure also shows that it is the two protocol interpreters that invoke the two data transfer functions, when necessary.

Data Representation

Numerous choices are provided in the FTP protocol specification to govern the way the file is transferred and stored. A choice must be made in each of four dimensions.

  1. File type.

    1. ASCII file type.

      (Default) The text file is transferred across the data connection in NVT ASCII. This requires the sender to convert the local text file into NVT ASCII, and the receiver to convert NVT ASCII to the local text file type. The end of each line is transferred using the NVT ASCII representation of a carriage return, followed by a linefeed . This means the receiver must scan every byte, looking for the CR, LF pair. (We saw the same scenario with TFTP's ASCII file transfer in Section 15.2.)

    2. EBCDIC file type.

      An alternative way of transferring text files when both ends are EBCDIC systems.

    3. Image file type. (Also called binary.)

      The data is sent as a contiguous stream of bits. Normally used to transfer binary files.

    4. Local file type.

      A way of transferring binary files between hosts with different byte sizes. The number of bits per byte is specified by the sender. For systems using 8-bit bytes, a local file type with a byte size of 8 is equivalent to the image file type.

  2. Format control. This choice is available only for ASCII and EBCDIC file types.

    1. Nonprint.

      (Default) The file contains no vertical format information.

    2. Telnet format control.

      The file contains Telnet vertical format controls for a printer to interpret.

    3. Fortran carriage control.

      The first character of each line is the Fortran format control character.

  3. Structure.

    1. File structure.

      (Default) The file is considered as a contiguous stream of bytes. There is no internal file structure.

    2. Record structure.

      This structure is only used with text files (ASCII or EBCDIC).

    3. Page structure.

      Each page is transmitted with a page number to let the receiver store the pages in a random order. Provided by the TOPS-20 operating system. (The Host Requirements RFC recommends against implementing this structure.)

  4. Transmission mode. This specifies how the file is transferred across the data connection.

    1. Stream mode.

      (Default) The file is transferred as a stream of bytes. For a file structure, the end-of-file is indicated by the sender closing the data connection. For a record structure, a special 2-byte sequence indicates the end-of-record and end-of-file.

    2. Block mode.

      The file is transferred as a series of blocks, each preceded by one or more header bytes.

    3. Compressed mode.

      A simple run-length encoding compresses consecutive appearances of the same byte. In a text file this would commonly compress strings of blanks, and in a binary file this would commonly compress strings of 0 bytes. (This is rarely used or supported. There are better ways to compress files for FTP.)

If we calculate the number of combinations of all these choices, there could be 72 different ways to transfer and store a file. Fortunately we can ignore many of the options, because they are either antiquated or not supported by most implementations .

Common Unix implementations of the FTP client and server restrict us to the following choices:

  • Type: ASCII or image.

  • Format control: nonprint only.

  • Structure: file structure only.

  • Transmission mode: stream mode only.

This limits us to one of two modes: ASCII or image (binary).

This implementation meets the minimum requirements of the Host Requirements RFC. (This RFC also requires support for the record structure, but only if the operating system supports it, which Unix doesn't.)

Many non-Unix implementations provide FTP capabilities to handle their own file formats. The Host Requirements RFC states "The FTP protocol includes many features, some of which are not commonly implemented. However, for every feature in FTP, there exists at least one implementation."

FTP Commands

The commands and replies sent across the control connection between the client and server are in NVT ASCII. This requires a CR, LF pair at the end of each line (i.e., each command or each reply).

The only Telnet commands (those that begin with IAC) that can be sent by the client to the server are interrupt process (<IAC, IP>) and the Telnet synch signal (<IAC, DM> in urgent mode). We'll see that these two Telnet commands are used to abort a file transfer that is in progress, or to query the server while a transfer is in progress. Additionally, if the server receives a Telnet option command from the client (WILL, WONT, DO, or DONT) it responds with either DONT or WONT.

The commands are 3 or 4 bytes of uppercase ASCII characters , some with optional arguments. More than 30 different FTP commands can be sent by the client to the server. Figure 27.2 shows some of the commonly used commands, most of which we'll encounter in this chapter.

Figure 27.2. Common FTP commands.
graphics/27fig02.gif

We'll see in the examples in the next section that sometimes there is a one-to-one correspondence between what the interactive user types and the FTP command sent across the control connection, but for some operations a single user command results in multiple FTP commands across the control connection.

FTP Replies

The replies are 3-digit numbers in ASCII, with an optional message following the number. The intent is that the software needs to look only at the number to determine how to process the reply, and the optional string is for human consumption. Since the clients normally output both the numeric reply and the message string, an interactive user can determine what the reply says by just reading the string (and not have to memorize what all the numeric reply codes mean).

Each of the three digits in the reply code has a different meaning. (We'll see in Chapter 28 that the Simple Mail Transfer Protocol, SMTP, uses the same conventions for commands and replies.)

Figure 27.3 shows the meanings of the first and second digits of the reply code.

Figure 27.3. Meanings of first and second digits of 3-digit reply codes.
graphics/27fig03.gif

The third digit gives additional meaning to the error message. For example, here are some typical replies, along with a possible message string.

  • 125 Data connection already open; transfer starting.

  • 200 Command OK.

  • 214 Help message (for human user).

  • 331 Username OK, password required.

  • 425 Can't open data connection.

  • 452 Error writing file.

  • 500 Syntax error (unrecognized command).

  • 501 Syntax error (invalid arguments).

  • 502 Unimplemented MODE type.

Normally each FTP command generates a one-line reply. For example, the QUIT command could generate the reply:

 221 Goodbye. 

If a multiline reply is needed, the first line contains a hyphen instead of a space after the 3-digit reply code, and the final line contains the same 3-digit reply code, followed by a space. For example, the HELP command could generate the reply:

 214- The following commands are recognized (* =>'s unimplemented)       USER    PORT    STOR    MSAM*   RNTO    NLST    MKD     CDUP       PASS    PASV    APPE    MRSQ*   ABOR    SITE    XMKD    XCUP       ACCT*   TYPE    MLFL*   MRCP*   DELE    SYST    RMD     STOU       SMNT*   STRU    MAIL*   ALLO    CWD     STAT    XRMD    SIZE       REIN*   MODE    MSND*   REST    XCWD    HELP    PWD     MDTM       QUIT    RETR    MSOM*   RNFR    LIST    NOOP    XPWD    214 Direct comments to ftp-bugs@bsdi.tuc.noao.edu. 

Connection Management

There are three uses for the data connection.

  1. Sending a file from the client to the server.

  2. Sending a file from the server to the client.

  3. Sending a listing of files or directories from the server to the client.

The FTP server sends file listings back across the data connection, rather than as multiline replies across the control connection. This avoids any line limits that restrict the size of a directory listing and makes it easier for the client to save the output of a directory listing into a file, instead of printing the listing to the terminal.

We've said that the control connection stays up for the duration of the client “server connection, but the data connection can come and go, as required. How are the port numbers chosen for the data connection, and who does the active open and passive open?

First, we said earlier that the common transmission mode (under Unix the only transmission mode) is the stream mode, and that the end-of-file is denoted by closing the data connection. This implies that a brand new data connection is required for every file transfer or directory listing. The normal procedure is as follows :

  1. The creation of the data connection is under control of the client, because it's the client that issues the command that requires the data connection (get a file, put a file, or list a directory).

  2. The client normally chooses an ephemeral port number on the client host for its end of the data connection. The client issues a passive open from this port.

  3. The client sends this port number to the server across the control connection using the PORT command.

  4. The server receives the port number on the control connection, and issues an active open to that port on the client host. The server's end of the data connection always uses port 20.

Figure 27.4 shows the state of the connections while step 3 is being performed. We assume the client's ephemeral port for the control connection is 1173, and the client's ephemeral port for the data connection is 1174. The command sent by the client is the PORT command and its arguments are six decimal numbers in ASCII, separated by commas. The first four numbers specify the IP address on the client that the server should issue the active open to (140.252.13.34 in this example), and the next two specify the 16-bit port number. Since the 16-bit port number is formed from two numbers, its value in this example is 4 — 256 + 150 = 1174.

Figure 27.4. PORT command going across FTP control connection.
graphics/27fig04.gif

Figure 27.5 shows the state of the connection when the server issues the active open to the client's end of the data connection. The server's end point is at port 20.

Figure 27.5. FTP server doing active open of data connection.
graphics/27fig05.gif

The server always does the active open of the data connection. Normally the server also does the active close of the data connection, except when the client is sending a file to the server in stream mode, which requires the client to close the connection (which gives the server the end-of-file notification).

It is also possible for the client to not issue the PORT command, in which case the server issues the active open to the same port number being used by the client for its end of the control connection (1173 in this example). This is OK, since the server's port numbers for the two connections are different: one is 20 and the other is 21. Nevertheless, in the next section we'll see why current implementations normally don't do this.



TCP.IP Illustrated, Volume 1. The Protocols
TCP/IP Illustrated, Vol. 1: The Protocols (Addison-Wesley Professional Computing Series)
ISBN: 0201633469
EAN: 2147483647
Year: 1993
Pages: 378

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net