File Transfer Protocol

Published on January 2017 | Categories: Documents | Downloads: 98 | Comments: 0 | Views: 434
of 23
Download PDF   Embed   Report

Comments

Content

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.
you today?" How may I help

Clinton: "Hello, this is Carl Clinton.
mailbox number MB1234."

I would like to access

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. when you have finished." Tell me

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

2

"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." Server: "My assistant is calling your fax machine now." Server: "My assistant has finished faxing the item." Clinton: "Thank you, that is all. Server: "Goodbye."
Good bye."

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 Server: 250 "/home/MB1234/Bills" is
new working directory.

Change directory to "Bills."

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

The client wants the server to send to port number 1930 on IP 3

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 Server: 150 Opening ASCII mode data
connection for /bin/ls.

Send the list of files in "Bills." The server now connects out from its port 20 on 172.16.62.36 to port 1930 on 192.168.1.2. That succeeded, so the data is now sent over the established data connection. The client wants the server to send to port number 1931 on the client machine.

Server: 226 Listing completed.

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

Server: 200 PORT command successful. Client: RETR Yoyodyne.TXT Server: 150 Opening ASCII mode data
connection for Yoyodyne.TXT.

Download "Yoyodyne.TXT." The server now connects out from its port 20 on 172.16.62.36 to port 1931 on 192.168.1.2. That succeeded, so the data is now sent over the established data connection.

Server: 226 Transfer completed.

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

4

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

5

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

6

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

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.

7

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!).
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
8

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.

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:
y

allow file sharing between remote machines 9

y y

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:
y y

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:
y

y

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

10

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:
y y y y

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:
y y y

Access control commands Transfer parameter commands FTP service commands Access control commands

Command USER

Description

Character string allowing the user to be identified. User identification is necessary to establish communication over the data channel. Character string specifying the user's password. This command must immediately 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 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 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 directory. It was introduced to solve problems of naming the parent directory 11

PASS

ACCT

CWD

CDUP

according to the system (generally ".."). SMNT REIN Structure Mount: Reinitialize: Command enabling the current session to be terminated. The server waits to finish the transfer in progress if the need arises, then supplies a response before closing the connection. Transfer parameter commands Command PORT Description

QUIT

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 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 specified. 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 Compressed). FTP service commands

PASV

TYPE STRU MODE

Command RETR

Description

This command (RETRIEVE) asks the server DTP for a copy of the file whose access path is given in the parameters. This command (store) asks the server DTP to accept the data sent over the data 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 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 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 hold the file whose name is given in the argument.

STOR

STOU

APPE

ALLO

12

REST

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 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 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 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 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 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 the directory to be deleted is indicated in the parameters. This command (make directory) causes a directory to be created. The name of the directory to be created is indicated in the parameters. This command (print working directory) makes it possible to resend the complete current directory path. 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 list of files in the directory placed in the parameter. This command (name list) enables the list of files and directories present in the current directory to be sent. This command (site parameters) causes the server to offer specific services not defined in the FTP protocol. 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 access path in the argument, it then returns the same information as LIST but 13

RNFR

RNTO

ABOR

DELE

RMD

MKD

PWD

LIST

NLST

SITE SYST STAT

over the control channel. HELP This command gives all the commands understood by the server. The information is returned on the control channel. This command (no operations) is only used to obtain an OK command from the server. It can only be used in order not to be disconnected after an excessive period of inactivity.

NOOP

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:
y y y

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

Digit 1yz

Meaning

Description

Preliminary positive The action requested is in progress, a second response must be response obtained before sending a second command Positive fulfilment The action requested has been fulfilled, a new command can be response sent Intermediary positive response The action request is temporarily suspended. Additional information is awaited from the client

2yz

3yz

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

14

Second number Digit x0z Syntax Meaning Description The action has a syntax error, or is a command not understood by the server This is a response sending back information (for example a response to a STAT command) The response relates to the data channel The response relates to the (USER/PASS) login or the request to change the account (CPT)

x1z Information x2z Connections x3z Authentication and accounts Not used by the FTP protocol

x4z

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 Transport layer Network layer Data link layer HTTP, SMTP, FTP, SSH, IRC, SNMP, SIP ... TCP, UDP, SCTP, RTP, DCCP ... IPv4, IPv6, ARP, ICMP ... Ethernet, 802.11a/b/g WiFi , Token ring, FDDI, ...

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]

15

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. 2. 3. 4. To promote sharing of files (computer programs and/or data). To encourage indirect or implicit use of remote computers. To shield a user from variations in file storage systems among different hosts. 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.

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
16

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.

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.

17

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 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:

18

y y y

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

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.

Read more: How to Use an FTP Server | eHow.com http://www.ehow.com/how_5037951_useftp-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

20

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 :

21

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

........

..........

22

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

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close