Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

Block Mode

This is a more “conventional” data transmission mode in which data is broken into data

blocks and encapsulated into individual FTP blocks, or records. Each record has a three-

byte header that indicates its length and contains information about the data blocks being

sent. A special algorithm is used to keep track of the transmitted data and to detect and

restart an interrupted transfer.

Compressed Mode

A transmission mode where a relatively simple compression technique called run-length

encoding is used to detect repeated patterns in the data being sent, and then represent

them in such a way that the overall message takes fewer bytes. The compressed infor-

mation is then sent in a way similar to block mode, using a header+payload record format.

Compressed mode seems on the surface to be useful. In practice, however, compression is

often implemented in other places in a typical networking software stack, making it unnec-

essary in FTP. For example, if you are transferring a file over the Internet using an analog

modem, your modem normally performs compression down at layer one. Large files on FTP

servers are also often already compressed using something like the ZIP format, meaning

further compression would serve no purpose.

Key Concept: FTP includes three different transmission modes: stream, block and

compressed. In stream mode, data is sent as a continuous sequence of bytes; in

block mode, data is formatted into blocks with headers; and in compressed mode,

bytes are compacted using run-length encoding. Stream mode is the one most commonly

used.

FTP Data Representation: Data Types, Data Structures and Format Control

The most general way of designing the File Transfer Protocol would have been to make it

treat all files as “black boxes”. The file would be represented as just as a set of bytes. FTP

would pay no attention to what the file contained, and would simply move the file, one byte

at a time, from one place to another. In this, it would seem to be very similar to the “copy”

command that is implemented on most file systems, which likewise creates a copy without

looking into the file to see what it contains.

So what would be the problem with that, you may wonder? Well, for some types of files, this

is exactly what we want, but for others, it introduces a problem. The reason is that certain

types of files use different representations on different systems. If you copy a file from one

place to another on the same computer using a “copy” command, there is no problem: the

same representation for files is used everywhere within that computer. But when you copy it

to a computer that uses a different representation, however, you may encounter difficulties.

The most common example of this is a type of file that may surprise you: simple text files.

All ASCII text files use the ASCII character set, but they differ in the control characters used

to mark the end of a line of text. On UNIX, a line feed (LF) character is used; on Apple

computers, a carriage return (CR); and Windows machines used both (CR+LF).

If you move a text file from one type of system to another using regular FTP, the data will all

get moved exactly as it was. Moving a text file from a UNIX system to a PC as just a set of

bytes would mean programs would not properly recognize end of line markers. Avoiding

this predicament requires that FTP move past the idea that “all files are just bytes” and

incorporate some intelligence to handle different types of files. The FTP standard recog-

nizes this by allowing the specification of certain details about the file's internal

representation prior to transfer.

FTP Data Types

The first piece of information that can be given about a file is its data type, which dictates

the overall representation of the file. There are four different data types specified in the FTP

standard:

☯ ASCII: Defines an ASCII text file, with lines marked by some sort of end-of-line marker

as described above.

☯ EBCDIC: Conceptually the same as the ASCII type, but for files using IBM's EBCDIC

character set.

☯ Image: The file has no formal internal structure and is sent one byte at a time without

any processing; this is the “black box” mode I mentioned above.

☯ Local: This data type is used to handle files that may store data in logical bytes

containing a number of bits other than 8. Specifying this type along with the way the

data is structured allows the data to be stored on the destination system in a manner

consistent with its local representation.

Note: The term “byte” conventionally refers to 8 bits but strictly speaking, the term

for 8 bits is “octet”. A byte may in fact contain a number of bits other than 8 on

certain systems. See the background topic on bits and bytes for the details.

In practice, the two data types most often used are ASCII and image. The ASCII type is

used for text files, and allows them to be moved between systems with line-end codes

converted automatically. The Image type is used for generic binary files, such as graphical

images, ZIP files and other data that is represented in a universal manner. It is also often

called the binary type for that reason.

ASCII Data Type Line Delimiting Issues

When the ASCII data type is used, differences in internal representations between systems

are handled by using a universal external representation that acts as a “common language”.

Lines of the file being transmitted are converted by the sending FTP process from the

sender's internal representation to the neutral ASCII representation used by the Telne t

protocol (“NETASCII”) with each line ending in “CR+LF”. The receiving device then converts

from this neutral representation to the internal format used by the recipient file system.

For example, when using FTP to move a text file from a Macintosh to a UNIX system, each

line would have the “CR” changed to a “CR+LF” for transmission over the FTP data

channel. The receiving UNIX system would change each “CR+LF” to just “LF”, so UNIX

programs would read it properly.

Note that this actually does mean the resulting file can be bigger or smaller than the

original, if it is transferred between systems using ASCII mode. Also, since FTP works by

converting to a neutral representation for universality, sending an ASCII file from a UNIX

system to a UNIX system means each “LF” is changed to “CR+LF” for transmission, then

changed back to just “LF” by the recipient. Slightly inefficient, but not that big a deal.

It's very important that when FTP is used, the correct data type be specified with the appro-

priate user command. Sending a text file between dissimilar systems without setting ASCII

mode will result in either a file that cannot be properly read on the destination, or one that

has stray characters in it. Conversely, binary files must be sent in binary mode. If you send

something like a ZIP file or a JPG graphic in ASCII mode, the FTP software will think it is a

text file. It will treat the file as if it were text, and each time it encounters bytes in the file that

look like “CR”, “LF” or “CR+LF” it will convert them, which you do not want. (Having the

wrong data type set is a leading cause of corrupted files when using FTP to move files

between PCs and UNIX systems. I know from experience!)

Key Concept: FTP defines four data types: ASCII, EBCDIC, image and local. ASCII

and EBCDIC are used for text files in the ASCII and EBCDIC character sets, respec-

tively; the image type is used for files with no specific structure, and the local type for

local representation. The ASCII type is important because it allows text files to be trans-

ferred successfully between file systems that may use different methods of indicating the

end of a line of text. The image type, also called binary, is used for files that must be sent

and received byte-for-byte with no transformation, such as executable files, graphics and

files with arbitrary formats.

FTP Format Control

For the ASCII and EBCDIC types, FTP defines an optional parameter called format control.

This allows a user to specify a particular representation for how vertical formatting is used

to describe a file. The three options are:

☯ Non Print: The default, indicating no vertical formatting.

☯ Telnet Format: Indicates that vertical format control characters, as specified in the

Telnet protocol, are used in this file.

☯ Carriage Control / FORTRAN: The file uses format control characters given as the

first character of each line, as specified for the FORTRAN programming language.

The format control option was created for the particular purpose of properly handling files

transferred from host devices to printers. It is not used today, to my knowledge (or if it is

used, it is only in special applications.)

FTP Data Structures

In addition to specifying a file's data type, it is also possible to specify the file's data

structure. There are three possibilities:

☯ File Structure: The file is a contiguous stream of bytes with no internal structure.

☯ Record Structure: The file consists of a set of sequential records, each of which is

delimited by an end-of-record marker.

☯ Page Structure: The file contains a set of special indexed data pages.

The file structure is the default and is used for most types of files. The record structure can

be used for ASCII text files, but these are more commonly sent with the regular file structure

using the ASCII data type. The page structure is not commonly used; I believe it was initially

created for a now archaic type of computer used in the early ARPAnet.

FTP Commands and Replies

In the previous section I discussed the general operation of the File Transfer Protocol. As

part of this description I explained how data transfers are performed, how connections are

established and managed, and the various transmission modes and data types that FTP

supports. All of these functions are implemented using a special set of FTP commands sent

by the User-FTP process to the Server-FTP process. The server device acknowledges

commands by sending back replies using special codes. Understanding FTP commands

and reply codes will allow us to see fully how the protocol works.

I begin the section by discussing FTP commands and how they are grouped. I then show

the special encoding format used for FTP reply codes, and list some of the more common

and important codes. I also discuss the FTP user interface and the commands used by

typical FTP implementations to allow a user to communicate with the FTP software. These

commands are usually different than the internal FTP commands, to allow the user to

operate the protocol in a way more friendly to humans.

FTP Internal Protocol Commands and Command Groups

An FTP session begins with the establishment of a TCP connection from an FTP client

(user device) to an FTP server. Once established, the control channel is logically in place

between the Server-PI and the User-PI. All communication to manage the operation of the

protocol takes place over this channel. The User-PI sends protocol commands to the

Server-PI, which processes them and takes appropriate action. The Server-PI responds

back with reply codes to tell the User-PI the result of the commands it issued and convey

other important information.

FTP Command Groups

Each command is identified by a short three-letter or four-letter command code for conve-

nience, and performs a specific task in the overall functionality of FTP. There are several

dozen of these protocol commands, and to help organize them, the FTP standard catego-

rizes them into three groups, based on overall function type:

☯ Access Control Commands: Commands that are part of the user login and authenti-

cation process, are used for resource access, or are part of general session control.

☯ Transfer Parameter Commands: Commands that specify parameters for how data

transfers should occur. For example, commands in this group specify the data type of

a file to be sent, indicate whether passive or active data connections will be used, and

so forth.

☯ FTP Service Commands: This is the largest group, containing all the commands that

actually perform file operations, such as sending and receiving files. Commands to

implement support functions, such as deleting or renaming files, are also here.

Interestingly, the actual transmission of FTP commands over the control channel is done

using specifications based on the Telnet protocol. You may recall from the FTP overview

that Telnet and FTP are two of the very oldest TCP/IP applications, the former being for

“direct” network use and the latter for “indirect” resource access. They were developed at

around the same time, and setting up the FTP control channel to act as a type of Telnet

connection is a good example of how Internet standards try not to “reinvent the wheel”.

Key Concept: FTP operation is controlled through the issuing of protocol commands

from the FTP client to the FTP server. Each command has a three- or four-letter

command code that indicates its function. The commands are organized into three

groups: access control commands used for login and general session control; transfer

parameter commands that control how transfers are performed; and FTP service

commands, which are used to perform actual file operations.

FTP Protocol Commands

Since the commands are based on the Telnet specifications, they are just sent as plain text

as specified by Telnet's Network Virtual Terminal (NVT) conventions. I have provided below

three tables that describe the FTP internal protocol commands in the order that they appear

in the FTP standard (RFC 959). Table 226 covers FTP access control commands, Table

227 lists transfer parameter commands, and Table 228 service commands.

Table 226: FTP Access Control Commands (Page 1 of 2)

Command

Code

Command Description

USER User Name Identifies the user attempting to establish an FTP session.

PASS Password

Specifies the password for the user given previously by the USER

command during login authentication.

ACCT Account

Specifies an account for an authenticated user during the FTP session.

Only used on systems that require this to be separately identified; most

select an account automatically based on the name entered in the USER

command.

CWD

Change Working

Directory

Displays the current server working directory for the FTP session; shows

the user “where they are” in the server's file system.

LIST List

Requests a list of the contents of the current directory from the server,

including both names and other information. Similar in concept to the

“DIR” command in DOS/Windows or the “ls” command in UNIX.

NLST Name List Like LIST, but returns only the names in a directory.

SITE Site Parameters Used to implement site-specific functions.

SYST System

Requests that the server send to the client information about the server's

operating system.

STAT Status

Prompts the server to send an indication of the status of a file or the

transfer currently in progress.

HELP Help

Asks the server for any help information that might be useful in allowing

the user to determine how the server should be used.

NOOP No Operation

Does nothing, other than prompting the server to send an “OK” response

to verify that the control channel is alive.

Table 228: FTP Service Commands (Page 2 of 2)

Command

Code

Command Description

FTP Replies, Reply Code Format and Important Reply Codes

Each time that the User-PI sends a command to the Server-PI over the control connection,

the server sends back a reply. FTP replies serve three main purposes. First, they serve as

confirmation that the server received a command. Second, they tell the user device whether

the command was accepted or not, and if an error occurred, what it was. Third, they

communicate various types of information to the user of the session, such as the status of a

transfer.

The Advantages of Using Both Text and Numeric Replies

For a human user, a string of reply text would be sufficient to satisfy the requirements

above, and FTP replies do include descriptive text. But having only a text string would make

it difficult or impossible for FTP software on the client side to interpret results coming from

the server. FTP was designed to also allow software applications to interact with each other

over the FTP command link. For this reason, the protocol designed its reply system around

the use of reply codes.

FTP reply codes are three-digit numeric responses that can be easily interpreted by a

computer program. They are also useful for human users who are familiar with FTP,

because they communicate at a glance the results of various operations. While each FTP

server implementation may differ in the text sent for each type of reply, the reply codes are

used in a consistent manner based on the specifications of the FTP standard. It is therefore

the codes that are examined to determine the results of a command; the text is just

descriptive.

Reply Code Structure and Digit Interpretation

To make reply codes even more useful, the codes are not just assigned in a linear or

random order, but a special encoding scheme is used. Each code has three digits that each

communicate a particular type of information and to categorize replies. A code can be

considered to be of the form “xyz”, where “x” is the first digit, “y” the second and “z” the third.

Key Concept: Each command sent by the FTP client results in a reply sent by the

FTP server. FTP replies consist of a three-digit numeric reply code, along with a line

of descriptive text. The reply code serves to standardize FTP replies, both so they

can be interpreted by client software, and so experienced users can see at a glance what

the results were of a command. The reply code is structured so that the first two digits

indicate the type of reply and to what category it belongs.

First Reply Code Digit (“x”)

The first digit of the reply code indicates the success or failure of the command in general

terms, whether a successful command is complete or incomplete, and whether an unsuc-

cessful one should be tried again or not. Table 229 shows the possible values.

Second Reply Code Digit (“y”)

The second digit is used to categorize messages into functional groups. These groups are

shown in Table 230.

Table 229: FTP Reply Code Format: First Digit Interpretation

Code

Format

Meaning Description

1yz

Positive

Preliminary Reply

An initial response indicating that the command has been accepted and

processing of it is still in progress. The user should expect another reply

before a new command may be sent.

2yz

Positive

Completion Reply

The command has been successfully processed and completed.

3yz

Positive Interme-

diate Reply

The command was accepted, but processing of it has been delayed,

pending receipt of additional information. This type of reply is used in

the middle of command sequences. For example, it is used as part of

the authentication sequence after receiving a USER command but

before the matching PASS command is sent.

4yz

Transient Negative

Completion Reply

The command was not accepted and no action was taken, but the error

is temporary and the command may be tried again. This is used for

errors that may be a result of temporary glitches or conditions that may

change; for example, a file being “busy” due to another resource

accessing it at the time a request was made for it.

5yz

Permanent

Negative

Completion Reply

The command was not accepted and no action was taken. Trying the

same command again is likely to result in another error. For example, a

request for a file that is not found on the server would fall into this

category, or sending an invalid command like “BUGU”. ☺

Table 230: FTP Reply Code Format: Second Digit Interpretation (Page 1 of 2)

Code

Format

Meaning Description

x0z Syntax Syntax errors or miscellaneous messages.

x1z Information Replies to requests for information, such as status requests.

x2z Connections Replies related to the control connection or data connection.

x3z

Authentication and

Accounting

Replies related to login procedures and accounting.