File Transfer Protocol

Show me everything on Cloud computing and SaaS

definition -

File Transfer Protocol (FTP), a standard Internet protocol, is the simplest way to exchange files
between computers on the Internet. Like the Hypertext Transfer Protocol (HTTP), which
transfers displayable Web pages and related files, and the Simple Mail Transfer Protocol
(SMTP), which transfers e-mail, FTP is an application protocol that uses the Internet's TCP/IP
protocols. FTP is commonly used to transfer Web page files from their creator to the computer
that acts as their server for everyone on the Internet. It's also commonly used to download
programs and other files to your computer from other servers.

As a user, you can use FTP with a simple command line interface (for example, from the
Windows MS-DOS Prompt window) or with a commercial program that offers a graphical user
interface. Your Web browser can also make FTP requests to download programs you select from
a Web page. Using FTP, you can also update (delete, rename, move, and copy) files at a server.
You need to logon to an FTP server. However, publicly available files are easily accessed using
anonymous FTP.

Basic FTP support is usually provided as part of a suite of programs that come with TCP/IP.
However, any FTP client program with a graphical user interface usually must be downloaded
from the company that makes it.

An Overview of the File Transfer Protocol

The File Transfer Protocol (FTP) was one of the first efforts to create a standard means of
exchanging files over a TCP/IP network, so the FTP has been around since the 1970's.  The FTP
was designed with as much flexibility as possible, so it could be used over networks other than
TCP/IP, as well as being engineered to have the capability with exchanging files with a broad
variety of machines.

The base specification is RFC 959 and is dated October 1985.  There are some additional RFCs
relating to FTP, but it should be noted that even as of this writing (December 2001) that most of
the new additions are not in widespread use.  The purpose of this document is to provide general
information about how the protocol works without getting into too many technical details.  RFC
959 should be consulted for details on the protocol.

Control Connection -- the conversation channel

The protocol can be thought of as interactive, because clients and servers actually have a
conversation where they authenticate themselves and negotiate file transfers.  In addition, the
protocol specifies that the client and server do not exchange data on the conversation channel. 

1
Instead, clients and servers negotiate how to send data files on separate connections, with one
connection for each data transfer.  Note that a directory listing is considered a file transfer.

To illustrate, we'll just present (an admittedly contrived) example of how the FTP would work
between human beings rather than computer systems.  For our example, we'll assume we have a
client, Carl Clinton, who wishes to transfer files from Acme Mail Service that manages his post
office box.  Below is a transcript of a phone call between Carl Clinton and Acme Mail Service.

Clinton: (Dials the phone number for the mail service)

Service: "Hello, this is the Acme Mail Service.  How may I help
you today?"

Clinton: "Hello, this is Carl Clinton.  I would like to access

mailbox number MB1234."

Service: "OK, Mr. Clinton, I need to verify that you may access
mailbox MB1234.  What is your password?"

Clinton: "My password is QXJ4Z2AF."

Service: "Thank you Mr. Clinton, you may proceed."

Clinton: "For now, I'm only interested in looking at the bills

and invoices, so look at the folder marked "bills" in my
mailbox."

Service: "OK."

Clinton: "Please prepare to have your assistant call my secretary

at +1 402 555 1234."

Service: "OK."

Clinton: "Now call my secretary and tell him the names of all the
items in the bills folder of my mailbox.  Tell me when
you have finished."

Server: "My assistant is calling your secretary now."

Server: "My assistant has sent the names of the items."

Clinton: (Receives the list from his secretary and notices a bill from Yoyodyne
Systems.)

"Please prepare to have your assistant send to my fax

machine +1 402 555 7777."
Service: "OK."

Clinton: "Now fax a copy of the bill from Yoyodyne Systems."

2
 Server: "My assistant is calling your fax machine now."

Server: "My assistant has finished faxing the item."

Clinton: "Thank you, that is all.  Good bye."

Server: "Goodbye."

Now let's look at how this same conversation would appear between computer systems
communicating with the FTP protocol over a TCP/IP connection.

Client: Connects to the FTP service at

port 21 on the IP address
172.16.62.36.

Server: 220 Hello, this is the Acme

Mail Service.

Client: USER MB1234

Server: 331 Password required to access

user account MB1234.

Client: PASS QXJ4Z2AF Note that this password is not

encrypted.  The FTP is susceptible
to eavesdropping!

Server: 230 Logged in.

Client: CWD Bills Change directory to "Bills."

Server: 250 "/home/MB1234/Bills" is new

working directory.

Client: PORT 192,168,1,2,7,138 The client wants the server to

send to port number 1930 on IP
address 192.168.1.2.  In this case,
192.168.1.2 is the IP address of
the client machine.

Server: 200 PORT command successful.

Client: LIST Send the list of files in "Bills."

Server: 150 Opening ASCII mode data The server now connects out
connection for /bin/ls. from its port 20 on 172.16.62.36 
to port 1930 on 192.168.1.2.

3
 Server: 226 Listing completed. That succeeded, so the data is
now sent over the established
data connection.

Client: PORT 192,168,1,2,7,139 The client wants the server to

send to port number 1931 on the
client machine.

Server: 200 PORT command successful.

Client: RETR Yoyodyne.TXT Download "Yoyodyne.TXT."

Server: 150 Opening ASCII mode data The server now connects out
connection for Yoyodyne.TXT. from its port 20 on 172.16.62.36
to port 1931 on 192.168.1.2.

Server: 226 Transfer completed. That succeeded, so the data is

now sent over the established
data connection.

Client: QUIT

Server: 221 Goodbye.

When using FTP, users use FTP client programs rather than directly communicating with the
FTP server.  Here's our same example using the stock "ftp" program which is usually installed
as /usr/bin/ftp on UNIX systems (and FTP.EXE on Windows).  The items the user types are in
bold.

ksh$ /usr/bin/ftp
ftp> open ftp.acmemail.example.com
Connected to ftp.acmemail.example.com (172.16.62.36).
220 Hello, this is the Acme Mail Service.
Name (ftp.acmemail.example.com:root): MB1234
331 Password required to access user account MB1234.
Password: QXJ4Z2AF
230 Logged in.
ftp> cd Bills
250 "/home/MB1234/Bills" is new working directory.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
-rw-r--r-- 1 ftpuser ftpusers 14886 Dec 3 15:22 Acmemail.TXT
-rw-r--r-- 1 ftpuser ftpusers 317000 Dec 4 17:40 Yoyodyne.TXT
226 Listing completed.
ftp> get Yoyodyne.TXT
local: Yoyodyne.TXT remote: Yoyodyne.TXT
200 PORT command successful.
150 Opening ASCII mode data connection for Yoyodyne.TXT.

4
226 Transfer completed.
317000 bytes received in 0.0262 secs (1.2e+04 Kbytes/sec)
ftp> quit
221 Goodbye.

As you can see, FTP is designed to allow users to browse the filesystem much like you would
with a regular UNIX  login shell or MS-DOS command prompt.  This differs from other
protocols that are transactional (i.e. HTTP), where a connection is established, clients issue a
single message to a server that replies with a single reply, and the connection is closed.  On the
other hand, client programs can be constructed to simulate a transactional environment if they
know in advance what they need to do.  In effect, FTP is a stateful sequence of one or more
transactions.

Command primitives, result codes and textual responses

The client is always responsible for initiating requests.  These requests are issued with FTP
command primitives, which are typically 3 or 4 characters each.  For example, the command
primitive to change the working directory is CWD.

The server replies are specially formatted to contain a 3-digit result code first, followed by a
space character, followed by descriptive text (there is also a format for multi-line responses). 
The protocol specifies that clients must only rely upon the numeric result code, since the
descriptive text is allowed to vary (with a few exceptions).  In practice, the result text is often
helpful for debugging, but is generally no longer useful for end users.

Authentication

Although it is not required by protocol, in effect clients must always login to the FTP server with
a username and password before the server will allow the client to access the service.  

There is also a de facto standard for guest access, where "anonymous" (or "ftp") are used as the
username and an e-mail address is customarily used as the password in a way for a polite netizen
to let the server administrator know who is using the guest login.  Because users do not want to
divulge their e-mail addresses to protect against unsolicited bulk e-mail, this has subsequently
evolved to the point where the password is just some arbitrary text.

Types of data connections

The protocol has built-in support for different types of data transfers.  The two mandated types
are ASCII for text (specified by the client sending "TYPE A" to the server), and "image" for
binary data (specified by "TYPE I").

ASCII transfers are useful when the server machine and client machine have different standards
for text.  For example, MS-DOS and Microsoft Windows use a carriage return and linefeed
sequence to denote an end-of-line, but UNIX systems use just a linefeed.  When ASCII transfers
are specified, this enables a client to always be able to translate the data into its own native text
format.

5
Binary transfers can be used for any type of raw data that requires no translation.  Client
programs should use binary transfers unless they know that the file in question is text.

The protocol does not have any advanced support for character sets for pathnames nor file
contents.  There is no way to specify UNICODE, for example.  For ASCII, it is 7-bit ASCII only.

Unfortunately, the burden of deciding what transfer type to use is left to the client, unlike HTTP,
which can inform the client what type of data is being sent.  Clients often simply choose to
transfer everything in binary, and perform any necessary translation after the file is downloaded. 
Additionally, binary transfers are inherently more efficient to send over the network since the
client and server do not need to perform on-the-fly translation of the data.

It should be noted that ASCII transfers are mandated by the protocol as the default transfer type
unless the client requests otherwise!

The PORT and PASV conundrum -- Active and Passive data connections

Although it was purposely designed into the protocol as a feature, FTP's use of separate data
connections cause numerous problems for things like firewalls, routers, proxies which want to
restrict or delegate TCP connections, as well as things like IP stacks which want to do dynamic
stateful inspection of TCP connections.  

The protocol does not mandate a particular port number or a direction that a data connection
uses.  For example, the easy way out would have been for the protocol's designers to mandate
that all data connections must originate from the client machine and terminate at port 20 on the
server machine.

Instead, for maximum flexibility, the protocol allows the client to choose one of two methods. 
The first method, which we'll call "Active", is where the client requests that the server originate a
data connection and terminate at an IP address and port number of the client's choosing.  The
important thing to note here is that the server connects out to the client.

Client: "Please connect to me at port 1931 on IP address

192.168.1.2, then send the data."

Server: "OK"

Or, the client can request that the server to assign an IP address and port number on the server
side and have the client originate a connection to the server address.  We call this method
"Passive" and note that the client connects out to the server.

Client: "Please tell me where I can get the data."

Server: "Connect to me at port 4023 on 172.16.62.36."

6
The active method uses the FTP command primitive PORT, so the first example using the actual
FTP protocol would resemble this:

Client: PORT 192,168,1,2,7,139

Server: 200 PORT command successful.

The passive method uses the FTP command primitive PASV, so the second example using the
actual FTP protocol would resemble this:

Client: PASV

Server: Entering Passive Mode (172,16,62,36,133,111)

It should be noted that FTP servers are required to implement PORT, but are not required to
implement PASV.  The default has traditionally been PORT for this reason, but in practice it is now
preferred to use PASV whenever possible because firewalls may be present on the client side
which often cause problems.

Partial data connections -- resuming downloads

The protocol provides a means to only transfer a portion of a file, by having a client specify a
starting offset into the file (using the REST primitive, i.e. "restart point").  If an FTP session fails
while a data transfer is in progress and has to be reestablished, a client can request that the server
restart the transfer at the offset the client specifies.  Note that not all FTP servers support this
feature.

Directory listings

The base standard of the FTP protocol provides two types of listings, a simple name list (NLST)
and a human-readable extended listing (LIST).  The name list consists of lines of text, where
each line contains exactly one file name and nothing else.

The extended listing is not intended to be machine-readable and the protocol does not mandate
any particular format.  The de facto standard is for it to be in UNIX "/bin/ls -l" format, but
although most servers try to emulate that format even on non-UNIX FTP servers, it is still
common for servers to provide their own proprietary format.  The important thing to note here is
that this listing can contain any type of data and cannot be relied upon.  Additionally, even those
that appear in "/bin/ls -l" format cannot be relied upon for the validity of the fields.  For
example the date and time could be in local time or GMT.

Newer FTP server implementations support a machine-readable listing primitive (MLSD) which is
suitable for client programs to get reliable metadata information about files, but this feature is
still relatively rare.  That leaves the simple name list as the only reliable way to get filenames,
but it doesn't tell a client program anything else (such as if the item is a file or a directory!).

7
Functional concerns

Despite a rich feature set, there are some glaring omissions.  For example, the base specification
doesn't even provide for clients to query a file's size or modification date.  However, most FTP
servers in use now support a de facto extension to the specification which provides the SIZE and
MDTM primitives, and even newer servers support the extremely useful MLSD and MSLT primitives
which can provide a wealth of information in a standardized format.

There is also no 100% accurate way for a client to determine if a particular pathname refers to a
file or directory, unless MLSD or MLST is available.  Since the protocol also does not provide a
way to transfer an entire directory of items at once, the consequence is that there is no 100%
accurate way to download an entire directory tree.

The end result is that FTP is not particularly suited to "mirroring" files and directories, although
FTP client programs use heuristics to make calculated guesses when possible.

Despite the guesswork that clients can use for determining metadata for files to download, there's
little they can do for files that they upload.  There is no standard way to preserve an uploaded
file's modification time.  FTP is platform agnostic, so there aren't standard ways to preserve
platform-specific metadata such as UNIX permissions and user IDs or Mac OS file type and
creator codes.

Separate connections for data transfers are also a mixed blessing.  For high performance it would
be best to use a single connection and perform multiple data transfers before closing it.  Even
better would be for a method to use a single connection for both the control connection
conversation and data transfers.  Since each data connection uses an ephemeral (random) port
number, it is possible to "run out" of connections.  For details on this phenomenon, a separate
article is available.

Security concerns

It is important to note that the base specification, as implemented by the vast majority of the
world's FTP servers, does not have any special handling for encrypted communication of any
kind.  When clients login to FTP servers, they are sending clear text usernames and passwords! 
This means that anyone with a packet sniffer between the client and server could surreptitiously
steal passwords.  

Besides passwords, potential attackers could not only monitor the entire conversation on the FTP
control connection, they could also monitor the contents of the data transfers themselves.

There have been proposals to make the FTP protocol more secure, but these proposals have not
seen widespread adoption.

Therefore, unless the IP protocol layer itself is secure (for example, encrypted using IPsec), FTP
should not be used if sensitive login information is to be exchanged over an insecure network, or
if the files containing sensitive material are being transferred over an insecure network.

8
Introduction to FTP protocol

FTP protocol (File Transfer Protocol) is, as its name indicates a protocol for transferring files.

The implementation of FTP dates from 1971 when a file transfer system (described in RFC141)
between MIT machines (Massachusetts Institute of Technology) was developed. Many RFC have
since made improvements to the basic protocol, but the greatest innovations date from July 1973.

The FTP protocol is currently defined by RFC 959 (File Transfer Protocol (FTP) -
Specifications).

The role of FTP protocol

FTP protocol defines the way in which data must be transferred over a TCP/IP network.

The aim of FTP protocol is to:

 allow file sharing between remote machines

 allow independence between client and server machine system files
 enable efficient data transfer

The FTP model

FTP protocol falls within a client-server model, i.e. one machine sends orders (the client) and the
other awaits requests to carry out actions (the server).

During an FTP connection, two transmission channels are open:

 A channel for commands (control channel)

 A channel for data

So, both the client and server have two processes allowing these two types of information to be
managed:

 DTP (Data Transfer Process) is the process in charge of establishing the connection and
managing the data channel. The server side DTP is called SERVER-DTP, the client side DTP is
called USER-DTP
 PI (Protocol Interpreter) interprets the protocol allowing the DTP to be controlled using
commands received over the control channel. It is different on the client and the server:
o The SERVER-PI is responsible for listening to the commands coming from a USER-PI over
the control channel on a data port, establishing the connection for the control channel,
receiving FTP commands from the USER-PI over this, responding to them and running
the SERVER-DTP.

9
 o The USER-PI is responsible for establishing the connection with the FTP server, sending
FTP commands, receiving responses from the SERVER-PI and controlling the USER-DTP if
needed.

When an FTP client is connected to a FTP server, the USER-PI initiates the connection to the
server according to the Telnet protocol. The client sends FTP commands to the server, the server
interprets them, runs its DTP, then sends a standard response. Once the connection is established,
the server-PI gives the port on which data will be sent to the Client DTP. The client DTP then
listens on the specified port for data coming from the server.
It is important to note that since the control and data ports are separate channels, it is possible to
send commands from one machine and receive data on another. So, for example it is possible to
transfer data between FTP servers by passing through a client to send control instructions and by
transferring information between two server processes connected on the right port.

In this configuration, the protocol imposes that the control channels remain open throughout the
data transfer. So a server can stop a transmission if the control channel is broken during
transmission.

The FTP commands

All communication conducted on the control channel follows Telnet protocol recommendations.
So, the FTP commands are Telnet character strings (in NVT-ASCII code) ending in the Telnet
end of line code (i.e. the sequence <CR>+<LF>, Carriage Return followed by the Line Feed
character, noted <CRLF>).
If the FTP command has a parameter, this is separated from the command by a space (<SP>).

FTP commands make it possible to specify:

 The port used

 The method of data transfer.
 Data structure
 The nature of the action to be conducted (Retrieve, List, Store, etc.)

There are three different types of FTP commands:

 Access control commands

 Transfer parameter commands
 FTP service commands

Access control commands

Command Description

USER Character string allowing the user to be identified. User identification is necessary

10
 to establish communication over the data channel.

Character string specifying the user's password. This command must immediately
PASS precede the USER command. It falls to the client to hide the display of this
command for security reasons.

Character string representing the user's account. The command is generally not
ACCT necessary. During the response accepting the password, if the response is 230
this stage is not necessary, if the response is 332, it is.

Change Working Directory: this command enables the current directory to be

CWD changed. This command requires the directory's access path to be fulfilled as an
argument.

Change to Parent Directory: this command allows you to go back to the parent
CDUP directory. It was introduced to solve problems of naming the parent directory
according to the system (generally "..").

SMNT Structure Mount:

REIN Reinitialize:

Command enabling the current session to be terminated. The server waits to

QUIT finish the transfer in progress if the need arises, then supplies a response before
closing the connection.

Transfer parameter commands

Command Description

PORT Character string allowing the port number used to be specified.

Command making it possible to indicate to the DTP server to stand by for a

PASV connection on a specific port chosen randomly from among the available ports.
The response to this command is the IP address of the machine and port.

This command enables the type of format in which the data will be sent to be
TYPE
specified.

STRU Telnet character specifying the file structure (F for File, R for Record, P for Page).

Telnet character specifying data transfer method (S for Stream, B for Block, C for
MODE
Compressed).

FTP service commands

Command Description

RETR This command (RETRIEVE) asks the server DTP for a copy of the file whose access

11
 path is given in the parameters.

This command (store) asks the server DTP to accept the data sent over the data
STOR channel and store them in a file bearing the name given in the parameters. If the
file does not exist, the server creates it, if not it overwrites it.

This command is identical to the previous one, only it asks the sever to create a
STOU
file where the name is unique. The name of the file is returned in the response.

Thanks to this command (append) the data sent is concatenated into the file
APPE
bearing the name given in the parameter if it already exists, if not, it is created.

This command (allocate) asks the server to plan a storage space big enough to
ALLO
hold the file whose name is given in the argument.

This command (restart) enables a transfer to be restarted from where it stopped.

To do so, the command sends the marker representing the position in the file
REST
where the transfer had been interrupted in the parameter. This command must
immediately follow a transfer command.

This command (rename from) enables a file to be renamed. In the parameters it

RNFR indicates the name of the file to be renamed and must be immediately followed
by the RNTO command.

This command (rename to) enables a file to be renamed. In the parameters it

RNTO indicates the name of the file to be renamed and must be immediately followed
by the RNFR command.

This command (abort) tells the server DTP to abandon all transfers associated
ABOR with the previous command. If no data connection is open, the DTP sever does
nothing, if not it closes it. The control channel however remains open.

This command (delete) allows a file to be deleted, the name of which is given in
DELE the parameters. This command is irreversible, confirmation can only be given at
client level.

This command (remove directory) enables a directory to be deleted. The name of

RMD
the directory to be deleted is indicated in the parameters.

This command (make directory) causes a directory to be created. The name of the
MKD
directory to be created is indicated in the parameters.

This command (print working directory) makes it possible to resend the complete
PWD
current directory path.

LIST This command allows the list of files and directories present in the current
directory to be resent. This is sent over the passive DTP. It is possible to place a
directory name in the parameter of this command, the server DTP will send the

12
 list of files in the directory placed in the parameter.

This command (name list) enables the list of files and directories present in the
NLST
current directory to be sent.

This command (site parameters) causes the server to offer specific services not
SITE
defined in the FTP protocol.

SYST This command (system) allows information on the remote server to be sent.

This command (status) makes it possible to transmit the status of the server, for
example to know the progress of a current transfer. This command accepts an
STAT
access path in the argument, it then returns the same information as LIST but
over the control channel.

This command gives all the commands understood by the server. The information
HELP
is returned on the control channel.

This command (no operations) is only used to obtain an OK command from the
NOOP server. It can only be used in order not to be disconnected after an excessive
period of inactivity.

The FTP responses

The FTP responses make it possible to ensure synchronisation between the client and FTP
server. So, at each command sent by the client, the server will potentially carry out an action and
systematically send back a response.

The responses are made up of a 3 digit code indicating the way in which the command sent by
the client has been processed. However, since this 3 digit code is hard to read for humans, it is
accompanied by a text (Telnet character string separated from the numeric code by a space).

The response codes are made up of 3 numbers the meanings of which are as follows:

 The first number indicates the status of the response (success or fail)
 The second number indicates what the response refers to.
 The third number gives a more specific meaning (relative to each second digit)

First number

Digi
Meaning Description
t

Preliminary positive The action requested is in progress, a second response must be

1yz
response obtained before sending a second command

2yz Positive fulfilment The action requested has been fulfilled, a new command can be

13
 response sent

Intermediary The action request is temporarily suspended. Additional

3yz
positive response information is awaited from the client

The action requested has not taken place because the command
Negative fulfilment
4yz has temporarily not been accepted. The client is requested to try
response
again later

The action requested has not taken place because the command
Permanent negative
5yz has not been accepted. The client is requested to formulate a
response
different request

Second number

Digi
Meaning Description
t

The action has a syntax error, or is a command not understood

x0z Syntax
by the server

This is a response sending back information (for example a

x1z Information
response to a STAT command)

x2z Connections The response relates to the data channel

Authentication and The response relates to the (USER/PASS) login or the request
x3z
accounts to change the account (CPT)

Not used by the FTP

x4z  
protocol

x5z File system The response relates to the remote file system

File transfer protocol - Definition

This page is about the File Transfer Protocol, a computer protocol. See Federal Theater Project for the US New Deal project.

Internet protocol suite   edit  (http://www.wordiq.com/definition/Template:IPstack)

Application layer HTTP, SMTP, FTP, SSH, IRC, SNMP, SIP ...

Transport layer TCP, UDP, SCTP, RTP, DCCP ...

Network layer IPv4, IPv6, ARP, ICMP ...

Data link layer Ethernet, 802.11a/b/g WiFi , Token ring, FDDI, ...

14
The File Transfer Protocol (FTP) is a software standard for transferring computer files between machines with widely
different operating systems. It belongs to the application layer of the Internet protocol suite.

FTP is an 8-bit client-server protocol, capable of handling any type of file without further processing, such as MIME or
Uuencode. However, FTP has extremely high latency; that is, the time between beginning the request and starting to receive
the required data can be quite long, and a sometimes-lengthy login procedure is required.

Contents [hide]

1 Overview

2 Active and passive mode

3 FTP and web browsers

4 References

5 See also

6 External links

Overview

FTP is commonly run on two ports, 20 and 21. Port 20 is a data stream which transfers the data between the client and the
server. Port 21 is the control stream and is the port where commands are passed to the ftp server. While data is being
transferred via the data stream, the control stream sits idle. This can cause problems with large data transfers through
firewalls which time out sessions after lengthy periods of idleness. While the file may well be successfully transferred, the
control session can be disconnected by the firewall, causing an error to be generated.

The objectives of FTP are:

1. To promote sharing of files (computer programs and/or data).

2. To encourage indirect or implicit use of remote computers.
3. To shield a user from variations in file storage systems among different hosts.
4. To transfer data reliably and efficiently.

Disadvantages are:

1. Passwords and file contents are sent in clear text, allowing eavesdropping which may be unwanted.
2. It is hard to filter active mode FTP traffic on the client side by using a firewall, since the client must open a random port in
order to make the connection. This problem is largely resolved by using passive mode FTP.
3. It is possible to tell a server to send to an arbitrary port of a third computer.

15
FTP, though usable directly by a user at a terminal, is designed mainly for use by FTP client programs.

Many sites that run FTP servers enable so-called "anonymous ftp". Under this arrangement, users do not need an account on
the server. By default, the account name for the anonymous access is 'anonymous'. This account does not need a password.
Although users are commonly asked to send their email addresses as their passwords for authentication, usually there is
trivial or no verification, depending on the FTP server and its configuration.

Active and passive mode

There are two modes that can be used for FTP: active and passive. Active mode requires both the client and the server to
open a port and listen on it in order to establish an FTP session. As this often causes problems with firewalls on the client
computer, passive mode was created. Passive mode requires only the server to have a process listen on a port, and thus it
bypasses firewall issues on the client computer.

An active mode FTP connection is established in the following manner:

1. A random unprivileged port (a port with a number above 1024, in this case we will call it x) is opened on the client and the
FTP program connects to port 21, known as the command port, on the server. The source port is now the random port
number x on the client and the destination port is port 21 on the server.
2. The client starts listening to port (x+1) and sends a PORT command to the server (via the server's command port 21) that tells
the server the port number it is listening to and that it is ready to receive data on this port. This port is known as the data
port.
3. The server opens source port 21 and connects to the client's data port. The source port is port 21, and the data port (x+1) is
the destination port.
4. The client opens a connection to port 21 on the server via the client's data port and then sends the server an
acknowledgment that it has established the connection.

FTP and web browsers

Most recent web browsers and file managers can connect to FTP servers. This allows manipulation of remote files over FTP
through an interface similar to that used for local files. This is done via an FTP URL, which takes the form
ftp://<ftpserveraddress>  (e.g., ftp://ftp.gimp.org/). A password can optionally be given in the URL, e.g.:
ftp://<login>:<password>@<ftpserveraddress>. Most web-browsers require the use of passive mode FTP, which not all
FTP servers are capable of handling.

Advantage of file transfer protocol

FTP - File Transfer Protocol - FTP allows you transfer files from one computer to another. A commonly
used protocol for exchanging files over any network, that supports the TCP/IP protocol. FTP is perhaps
the best, fastest and most efficient way to transfer large files over the Internet.

16
Understanding File Transfer Protocol

File transfer protocol is a file server that holds large files for downloading by other computers.
You upload your file to the file server and then it is available to others on the same network. The
file transfer or download happens all at once, which means you don't have to download each
individual file if you have a folder of files.

*Important Tip

When using a FTP file server make sure that it supports TCP/IP protocol.

The Advantages of File Transfer Protocol

· One of the biggest advantages of file transfer protocol is that it is one of the fastest ways to get
large files from one computer to another.

· It's also efficient because you don't need to complete many operations to get the entire file or
files transferred.

· Most FTP servers require you to log in with a username and password.

· FTP allows you to transfer files back and forth. This means that if you are an owner of a
company, you can send information to your employees and they can send information back all on
the same server.

Other File Protocols

The other two common forms of file transfer are HTTP and peer-to-peer (P2P). HTTP is a
website that users can use to either download files or save entire pages of information. HTTP is
the information you see in your web browser anytime you use HTTP at the beginning of your
web address bar. Unlike FTP, users cannot upload information to the HTTP web server. This
makes HTTP much more secure because it helps cut down on spam and other irrelevant file
uploads. The downside of using HTTP is that it's not the best way to transfer large files since the
user will have to download each file separately, making it much slower than FTP.

Peer to peer (P2P) does not have a server that holds all of the files available for transfer. Instead,
individual computers host the files and then other computers can access the files on the other
computers. This means that one computer can have many people downloading files from it. For
large based networks, P2P is not a desirable method of file transfer because it can make
computer systems run slower making it inefficient.

Conclusion

If you are looking for a file server that will be able to hold large files making it available for
download to a large group of people, FTP is probably your best bet. If you are looking for a

17
smaller file transfer system, HTTP or P2P might be easier for you. Another option is you can
always attempt to use HTTP and then convert to a FTP if need be in the future when you have
more information for transmission.

FTP Task

The FTP task downloads and uploads data files and manages directories on servers. For example,
a package can download data files from a remote server or an Internet location as part of an
Integration Services package workflow. You can use the FTP task for the following purposes:

 Copying directories and data files from one directory to another, before or after moving
data, and applying transformations to the data.
 Logging in to a source FTP location and copying files or packages to a destination
directory.
 Downloading files from an FTP location and applying transformations to column data
before loading the data into a database.

At run time, the FTP task connects to a server by using an FTP connection manager. The FTP
connection manager is configured separately from the FTP task, and then is referenced in the
FTP task. The FTP connection manager includes the server settings, the credentials for accessing
the FTP server, and options such as the time-out and the number of retries for connecting to the
server. For more information, see FTP Connection Manager.

Important
The FTP connection manager supports only anonymous authentication and basic authentication.
It does not support Windows Authentication.

When accessing a local file or a local directory, the FTP task uses a File connection manager or
path information stored in a variable. In contrast, when accessing a remote file or a remote
directory, the FTP task uses a directly specified path on the remote server, as specified in the
FTP connection manager, or path information stored in a variable. For more information, see File
Connection Manager and Integration Services Variables.

This means that the FTP task can receive multiple files and delete multiple remote files; but the
task can send only one file and delete only one local file if it uses a connection manager, because
a File connection manager can access only one file. To access multiple local files, the FTP task
must use a variable to provide the path information. For example, a variable that contains
"C:\Test\*.txt" provides a path that supports deleting or sending all the files that have a .txt
extension in the Test directory.

To send multiple files and access multiple local files and directories, you can also execute the
FTP task multiple times by including the task in a Foreach Loop. The Foreach Loop can
enumerate across files in a directory using the For Each File enumerator. For more information,
see Foreach Loop Container.

18
The FTP task supports the ? and * wildcard characters in paths. This lets the task access multiple
files. However, you can use wildcard characters only in the part of the path that specifies the file
name. For example, C:\MyDirectory\*.txt is a valid path, but C:\*\MyText.txt is not.

The FTP operations can be configured to stop the File System task when the operation fails, or to
transfer files in ASCII mode. The operations that send and receive files copy can be configured
to overwrite destination files and directories.

 Predefined FTP Operations

The FTP task includes a predefined set of operations. The following table describes these
operations.

Operation Description
Send files Sends a file from the local computer to the FTP server.
Receive files Saves a file from the FTP server to the local computer.
Create local directory Creates a folder on the local computer.
Create remote directory Creates a folder on the FTP server.
Remove local directory Deletes a folder on the local computer.
Remove remote directory Deletes a folder on the FTP server.
Delete local files Deletes a file on the local computer.
Delete remote files Deletes a file on the FTP server.

 Other Related Tasks

Integration Services includes a task that performs operations on files and directories in the file
system.

How to Use an FTP Server

By Ma Wen Jie, eHow Contributor
updated: August 21, 2009

Use an FTP Server

File Transfer Protocol (FTP) servers are one of the oldest and most reliable methods of file
sharing between computers. FTP servers and clients are available for all major platforms,
including Unix, Linux, Macintosh and Windows. FTP servers offer advantages in reliability,
security and efficiency, and offer good customization and configuration options. Access to FTP
servers requires an FTP client. Paid and open source clients, both command line and graphical
clients, are available for virtually all computing platforms.

19
Read more: How to Use an FTP Server | eHow.com http://www.ehow.com/how_5037951_use-
ftp-server.html#ixzz117AG7be6

FTP has two separate modes of operation: Active and Passive. You will use either one
depending on whether your PC is behind a firewall.

Active Mode FTP

Active mode is usually used when there isn't any firewall between you and the FTP server.
In such cases you have a direct connection to the Internet. When you (the client) try to
establish a connection to a FTP server, your workstation includes a second port number
(using the PORT command) that is used when data is to be exchanged, this is known as the
Data Channel.

The FTP server then starts the exchange of data from its own port 20 to whatever port was
designated by your workstation (in the screen shot, my workstation used port 1086), and
because the server initiated the communication, it's not controlled by the workstation client.
This can also potentially allow uninvited data to arrive to your computer from anywhere
posing as a normal FTP transfer. This is one of the reasons Passive FTP is more secure.

Passive Mode FTP

Using normal or passive FTP, a client begins a session by sending a request to communicate
through TCP port 21, the port that is conventionally assigned for this use at the FTP server.
This communication is known as the Control Channel connection.

At this point, a PASV command is sent instead of a PORT command. Instead of specifying a
port that the server can send to, the PASV command asks the server to specify a port it
wishes to use for the Data Channel connection. The server replies on the Control Channel
with the port number which the client then uses to initiate an exchange on the Data
Channel. The server will thus always be responding to client-initiated requests on the Data
Channel and the firewall can correlate these.

It's simple to configure your client FTP program to use either Active or Passive FTP.

For example, in Cute FTP, you can set your program to use Passive FTP by going to FTP-->
Settings --> Options and then selecting the "Firewall" tab :

20
If you remove the above options, then your workstation will be using (if possible) Active FTP
mode, and I say "if possible" cause if your already behind a firewall, there is probably no
way you will be using Active FTP, so the program will automatically change to Passive FTP
mode.

So let's have a look at the process of a computer establishing an FTP connection with a
server: .

........ ..........

21
The above is assuming a direct connection to the FTP server. For simplicity reasons, we are
looking at the way the FTP connection is created and not worring if it's a Passive or Active
FTP connection. Since FTP is using TCP as a transport, you would expect to see the 3-way
handshake. Once that is completed and there is data connection established, the client will
send its login name and then password. After the authentication sequence is finished and
the user is authenticated to the Server, it's allowed access and is ready to leach the site dry
:)

Finally, below are the most commonly used FTP commands:

ABOR: abort previous FTP command

LIST and NLST: list file and directories

DELE: delete a file

RMD: remove a directory

MKD: create a directory

PWD: print current working directory ( show you which dir. your at)

PASS: send password

PORT: request open port number on specific IP address/port number

QUIT: log off from server

RETR: retrieve file

STOR: send or put file

SYST: identity system type

TYPE: specify type (A for ASCII, I for binary)

USER: send username

And that just about complete's our analysis on the FTP protocol!

References

1. Internetworking With TCP/IP, Volume 1: Principles, Protocols, Architecture, Third

Edition, by Douglas E. Comer, ISBN 0-13-216987- 8, Prentice Hall, 1995.
2. R. Braden, "Requirements for Internet hosts application and support," RFC 1123,
October 1989.
3. S. Bellovin, "Firewall-Friendly FTP," RFC 1579, February 1994.
4. P. Deutsch, A. Emtage, A. Marine, "How to Use Anonymous FTP," RFC 1635, May
1994.

22