How FTP works?
The File Transfer Protocol (FTP) is defined by the RFC959 based on the FTP Model illustrated in the Figure 2-3. The FTP uses two TCP/IP connections, i.e., control connection and data connection between the User and the Server. The control connection manages and controls the Server to transfer files between the Server and the User through the data connection.
It is important for understanding the FTP that the RFC959 defines the protocol between User-FTP Process and Server-FTP Process, not between User and User-FTP Process nor User and Server-FTP Process, in the Model. You cannot see the conversation between the User-FTP Process and the Server-FTP Process, i.e., FTP protocol, directly, as you operate FTP through the User Interface.
Figure 2-3. The FTP Model (Session Layer)
Control Connection
The control connection is a full duplex communication path between Server and User for exchanging commands and replies (see Figure 2-4). The FTP uses the Telnet protocol, which is defined by the RFC854, for the control connection. An FTP Server passively waits at TCP port 21 for the establishment of control connection, which is initiated by the User. Once the control connection has established, the Server send a reply message and wait for User’s further attempt for login by accepting username and password for authentication. After authentication, i.e., the Server recognizes the legal login of the User, the Server replies login message and wait for next command to the operation.
.png)
(1) FTP Command
An FTP command string is a command word, may followed by a parameter string, terminated by a line delimiter sequence, namely a carriage return () and a line feed (). Each command word is a word of three or four capital letters. Format of some FTP command strings are shown below.
Command
|
Parameter
|
USER
| |
PASS
| |
QUIT
| |
PORT
| |
PASV
| |
TYPE
| |
RETR
| |
STOR
| |
ABOR
| |
LIST
|
[
|
HELP
|
[
|
NOOP
|
Table 2-1. Example of the FTP commands
(2) FTP Reply
Each of reply messages sent from FTP server is always consists of a three-digit number (reply code; transmitted as three numeric characters, xyz) followed by a text string. There are five values for the first digit of the reply code:
xyz
|
Meaning
|
1yz
|
Positive Preliminary reply
|
2yz
|
Positive Completion reply
|
3yz
|
Positive Intermediate reply
|
4yz
|
Transient Negative Completion reply
|
5yz
|
Permanent Negative Completion reply
|
Table 2-2. Description of the reply code (1st digit)
The second digit encodes function groupings as:
xyz
|
Meaning
|
x0z
|
Syntax
|
x1z
|
Information
|
x2z
|
Connections
|
x3z
|
Authentication and accounting
|
x5z
|
File system
|
Table 2-3. Description of the reply code (2nd digit)
The third digit gives a finer gradation of meaning in each of the function categories specified by the second digit.
(3) An Example
The example below shows an FTP operation on a Linux platform using an FTP client with character based traditional user interface, where the red , green, and blue texts denote inputs typed by the User, reply or prompt messages from the client software, and replies from the Server respectively. Although no FTP command, sent to the Server from the Client, are shown on the CRT, but "USER username", "PASS xxxxxx", and "QUIT" commands were issued background in this case.
An example of FTP operation with character based user interface:
$ ftp servername
|
user: start FTP client and connect to servername
| |
Connected to servername.
|
client: connection established
| |
220 servername FTP server ready.
|
server: connection acknowledged and wait for login
| |
Name (servername:defaultusername):username
|
user: enter username
client: send "USER username" command
| |
331 Password required for username.
|
server: accept username and wait for password of the username
| |
Password: xxxxxx (not shown on the screen)
|
user: enter password xxxxx
client: send "PASS xxxxxx" command
| |
230 User username logged in.
|
server: the username/password pair has been authenticated and the user username has logged in
| |
Remote system type is UNIX.
Using binary mode to transfer files.
|
client: reports current status
| |
ftp> bye
|
user: enter termination command
client: send "QUIT" command
| |
221 Goodbye.
|
server: QUIT acknowledged
| |
$
|
client: FTP client terminated
| |
Data Connection
Data connection is a full duplex communication link through which data (file) are transferred between Server and User on a specified type and mode. The data connection is established for data or file transfer on demand temporally (see Figure 2-5). Through the data connection, not only content of files but also other data or messages such as result of FTP commands, e.g., directory listing, help messages, are transferred.
.png)
(1) Active mode and Passive mode
Normally, data connection is initiated by the Server towards the User with no regard to the direction of data transfer. We call it as active or normal mode. In the active mode, the User passively waits for the establishment of connection from the Server (see Figure 2-6).
Some Users couldn’t transfer files in the active mode because firewalls between the User’s host and outer network block the connecting activity from outer network, e.g., Internet, due to security reasons. In this case, the FTP transfer will result in fail.
To cope well with such environment, the passive mode, a mode that initiates the connection from the User side, is prepared. In the passive mode, data connections are initiated from the User side same as the control connection and not blocked by firewalls.
.png)
Figure 2-6. Direction of FTP Connections
(2) Code Conversion
FTP handles limited type of data representation and conversion. Two major data types that most FTP software could handle are ASCII and BINARY (IMAGE).
The ASCII is default type and all FTP software must implement the type to transfer text file. For the ASCII type, the sender converts the data from an internal character representation to the standard 8-bit ASCII representation. The receiver will convert the standard form to its internal representation. Be careful that most FTP implementation doesn't support other character types than ASCII, especially multi-byte characters.
The BINARY type is highly recommended to implement in all FTP software. On the BINARY type, file is treated as a sequence of 8-bit data bytes (or octets) and must be stored as a series of contiguous bytes without modification. In short, file is transferred as it is in BINARY transfer mode.
[Tip] Although the uniqueness of the transferred file to the original one, there are possibility of incompatibility of data caused from the difference of data arrangement of multi-byte area in memory that comes from CPU design, e.g., big endian and little endian, or difference of floating point expressions. You don't have to worry on this point for the WMO codes, because all WMO binary codes, i.e., GRIB and BUFR, are byte oriented and have no flaws on the endians.
Remarks on the FTP
The FTP has some characteristics that may affect to or should be concerned with the operation when used in NMHCs or GTS centres.
(1) Password Exposure
To authenticate a User to the Server (via the USER and PASS FTP-commands), username and password are sent in clear text through control connection. It is not so difficult to capture or dump IP packet to get username and password with some tools. This password exposure leads computer to the risk of potential attack. The use of anonymous account and/or limit the accessibility of files will reduce those risks.
(2) Non-ASCII File Names
The RFC959 does not provide standard any pathname/filename convention and conversion. Each user has to obey the file naming conventions of the file systems involved in the transfer. If you name files using a code set incompatible to ASCII, especially multi-byte code, it may happen that the FTP transfer results in fail or created file will have illegal file name.
(3) Length of File Names
The RFC959 does not define maximum length of pathname and filename. Actually, maximum lengths are practically depending on the platforms and applications and vary case by case. In the worst case, the ftp client supplied with the old Windows could handle only eight-character name and 3-character extension, i.e., MS-DOS convention. Fortunately, recent systems could allow long file names that are defined in the WMO Manual on the GTS Attachment II-15. But length of a pathname is implementation dependent. You must be careful not to put files into profound directories.
(4) Absence of Relaying Function
The FTP protocol depends on the Client/Server Model. According to the model, the Client actively controls the Server to transfer files between them, while the Server act passively (see Figure 2-3). The server itself has no function of raise an event to invoke some subsequent functions after completion of a file transfer. This means that the FTP server itself doesn't actively relay files to a third host. To realize file relay/switching function, some client processes, which periodically check the existence of a file and invoke further file transfer, are required outside FTP.
Previous Page NextPage
Previous Page NextPage
Comments