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.
 Figure 2-4. Control Connection

(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
><LF>
PASS
><LF>
QUIT
><LF>
PORT
><LF>
PASV
><LF>
TYPE
><LF>
RETR
><LF>
STOR
><LF>
ABOR
><LF>
LIST
[ ] ><LF>
HELP
[ ] ><LF>
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.
 Figure 2-5. Data Connection

(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.
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

Comments

Anonymous said…
nice

Popular posts from this blog

How To Add Print Button to Blogger Posts

INSTALL CISCO VPN CLIENT ON WINDOWS 10 (32 & 64 BIT). FIX REASON 442