Article based on http://en.wikipedia.org/wiki/FTP<>

FTP or File Transfer Protocol is used to transfer data from one computer to another over the Internet, or through a network.

Specifically, FTP is a commonly used protocol for exchanging files over any network that supports the TCP/IP protocol (such as the Internet or an intranet). There are two computers involved in an FTP transfer: a server and a client. The FTP server, running FTP server software, listens on the network for connection requests from other computers. The client computer, running FTP client software, initiates a connection to the server. Once connected, the client can do a number of file manipulation operations such as uploading files to the server, download files from the server, rename or delete files on the server and so on. Any software company or individual programmer is able to create FTP server or client software because the protocol is an open standard. Virtually every computer platform supports the FTP protocol. This allows any computer connected to a TCP/IP based network to manipulate files on another computer on that network regardless of which operating systems are involved (if the computers permit FTP access). There are many existing FTP client and server programs. FTP servers can be set up anywhere between game servers, voice servers, internet hosts, and other physical servers.

FTP runs exclusively over TCP. FTP servers by default listen on port 21 for incoming connections from FTP clients. A connection to this port from the FTP Client forms the control stream on which commands are passed to the FTP server from the FTP client and on occasion from the FTP server to the FTP client. For the actual file transfer to take place, a different connection is required which is called the data stream. Depending on the transfer mode, the process of setting up the data stream is different.

In active mode, the FTP client opens a random port (> 1023), sends the FTP server the random port number on which it is listening over the control stream and waits for a connection from the FTP server. When the FTP server initiates the data connection to the FTP client it binds the source port to port 20 on the FTP server.

In order to use active mode, the client sends a PORT command, with the IP and port as argument. The format for the IP and port is "h1,h2,h3,h4,p1,p2″. Each field is a decimal representation of 8 bits of the host IP, followed by the chosen data port. For example, a client with an IP of 192.168.0.1, listening on port 1025 for the data connection will send the command "PORT 192,168,0,1,4,1″. The port fields should be interpreted as p1×256 + p2 = port, or, in this example, 4×256 + 1 = 1025.

In passive mode, the FTP server opens a random port (> 1023), sends the FTP client the server’s IP address to connect to and the port on which it is listening (a 16 bit value broken into a high and low byte, like explained before) over the control stream and waits for a connection from the FTP client. In this case the FTP client binds the source port of the connection to a random port greater than 1023.

To use passive mode, the client sends the PASV command to which the server would reply with something similar to "227 Entering Passive Mode (127,0,0,1,78,52)". The syntax of the IP address and port are the same as for the argument to the PORT command.

In extended passive mode, the FTP server operates exactly the same as passive mode, however it only transmits the port number (not broken into high and low bytes) and the client is to assume that it connects to the same IP address that was originally connected to. Extended passive mode was added by RFC 2428 in September 1998.

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 FTP protocol supports resuming of interrupted downloads using the REST command. The client passes the number of bytes it has already received as argument to the REST command and restarts the transfer. In some command line clients for example, there is an often-ignored but valuable command, "reget" (meaning "get again") that will cause an interrupted "get" command to be continued, hopefully to completion, after a communications interruption.

Resuming uploads is not as easy. Although the FTP protocol supports the APPE command to append data to a file on the server, the client does not know the exact position at which a transfer got interrupted. It has to obtain the size of the file some other way, for example over a directory listing or using the SIZE command

The original FTP specification is an inherently insecure method of transferring files because there is no method specified for transferring data in an encrypted fashion. This means that under most network configurations, user names, passwords, FTP commands and transferred files can be "sniffed" or viewed by anyone on the same network using a packet sniffer. This is a problem common to many Internet protocol specifications written prior to the creation of SSL such as HTTP, SMTP and Telnet. The common solution to this problem is to use either SFTP (SSH File Transfer Protocol), or FTPS (FTP over SSL), which adds SSL or TLS encryption to FTP as specified in RFC 42

Many sites that run FTP servers enable anonymous ftp. Under this arrangement, users do not need an account on the server. The user name for anonymous access is typically '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. As modern FTP clients hide the login process from the user and usually don’t know the user’s email address, they supply dummy passwords, for example:

        Mozilla Firefox (2.0) — mozilla@example.com

        KDE Konqueror (3.5) — anonymous@

        wget (1.10.2) — -wget@

        lftp (3.4.4) — lftp@

While transferring data over the network, several data representations can be used. The two most common transfer modes are:

        ASCII mode

        Binary mode: In "Binary mode", the sending machine sends each file bit for bit and as such the recipient stores the bitstream as it receives it.

In "ASCII mode", any form of data that is not plain text will be corrupted. When a file is sent using an ASCII-type transfer, the individual letters, numbers, and characters are sent using their ASCII character codes. The receiving machine saves these in a text file in the appropriate format (for example, a Unix machine saves it in a Unix format, a Windows machine saves it in a Windows format). Hence if an ASCII transfer is used it can be assumed plain text is sent, which is stored by the receiving computer in its own format. Translating between text formats entails substituting the end of line and end of file characters used on the source platform with those on the destination platform, e.g. a Windows machine receiving a file from a Unix machine will replace the line feeds with carriage return-line feed pairs.

By default, most FTP clients use ASCII mode. Some clients try to determine the required transfer-mode by inspecting the file’s name or contents.

The FTP specifications also list the following transfer modes:

        EBCDIC mode

        Local mode

In practice, these additional transfer modes are rarely used. They are however still used by some legacy mainframe systems.

Sorting algorithms used in computer science are often classified by:

       Computational complexity (worst, average and best behaviour) of element comparisons in terms of the size of the list (n). For typical sorting algorithms good behavior is O(n log n) and bad behavior is Ω(n²). (See Big O notation) Ideal behavior for a sort is O(n). Sort algorithms which only use an abstract key comparison operation always need Ω(n log n) comparisons in the worst case.

       Computational complexity of swaps (for "in place" algorithms).

       Memory usage (and use of other computer resources). In particular, some sorting algorithms are "in place", such that only O(1) or O(log n) memory is needed beyond the items being sorted, while others need to create auxiliary locations for data to be temporarily stored.

       Recursion. Some algorithms are either recursive or non recursive, while others may be both (e.g., merge sort).

       Stability: stable sorting algorithms maintain the relative order of records with equal keys (i.e. values). See below for more information.

       Whether or not they are a comparison sort. A comparison sort examines the data only by comparing two elements with a comparison operator.

       General method: insertion, exchange, selection, merging, etc. Exchange sorts include bubble sort and quicksort. Selection sorts include shaker sort and heapsort.

Article Based on http://msdn2.microsoft.com/en-us/library/aa383630.aspx

The Windows Internet (WinINet) application programming interface (API) enables applications to interact with Gopher, FTP, and HTTP protocols to access Internet resources. As standards evolve, these functions handle the changes in underlying protocols, enabling them to maintain consistent behavior

This section contains information about the handles that are used by the WinINet functions and the hierarchy in which they work.

The HINTERNET handles are maintained in a tree hierarchy. The handle returned by the InternetOpen function is the root node. Handles returned by the InternetConnect function occupy the next level. Handles returned by the FtpOpenFile, FtpFindFirstFile, HttpOpenRequest, GopherOpenFile, and GopherFindFirstFile functions are the leaf nodes.

The following diagram illustrates the hierarchy of the HINTERNET handles. Each box in the diagram represents a function that returns an HINTERNET handle.

At the top level is the InternetOpen function, which creates the root handle. The next level contains the InternetOpenUrl and InternetConnect functions. The functions that use the handle returned by InternetConnect make up the last level.

The following diagram shows the functions that are dependent on the handle created by InternetOpenUrl. The shaded boxes represent functions that return HINTERNET handles, while the plain boxes represent functions that use the HINTERNET handle created by the associated function.

The InternetQueryDataAvailable, InternetReadFile, and InternetSetFilePointer functions use the HINTERNET handle created by InternetOpenUrl.

The following diagram shows the FTP functions that are dependent on the FTP session handle returned by InternetConnect. The shaded boxes represent functions that return HINTERNET handles, while the plain boxes represent functions that use the HINTERNET handle created by the function on which they depend.

The FtpCreateDirectory, FtpDeleteFile, FtpGetCurrentDirectory, FtpGetFile, FtpPutFile, FtpRemoveDirectory, FtpRenameFile, and FtpSetCurrentDirectory functions all use the HINTERNET handle created by InternetConnect.

The following diagram shows the two FTP functions that return handles and the functions that are dependent on them. The shaded boxes represent functions that return HINTERNET handles, while the plain boxes represent functions that use the HINTERNET handle created by the function on which they depend.

The InternetFindNextFile function is dependent on the handle created by FtpFindFirstFile, while InternetReadFile and InternetWriteFile use the handle created by FtpOpenFile.

Let’s jump right into it and perform an FTP GET on the file DIRMAP.TXT at FTP.MICROSOFT.COM and storing the file in C:\DIRMAP.TXT. Once again the basic steps are

1.    Setup the environment with a call to InternetOpen.

2.    Connect to the host by calling the InternetConnect function.

3.    Call the FtpGetFile function to get the file.

4.    Close the handles created in Steps 1 and 2, using the InternetCloseHandle function

Setup the environment by calling the InternetOpen function.

HINTERNET WINAPI InternetOpen(

  LPCTSTR lpszAgent,

  DWORD dwAccessType,

  LPCTSTR lpszProxy,

  LPCTSTR lpszProxyBypass,

  DWORD dwFlags

);

And here’s the QTP-specific declaration for the function call:

Extern.Declare micLong, "InternetOpen", "wininet.dll", "InternetOpenA",

micString, micDWord, micString, micString, micDWord

The lpszAgent parameter is used to specify the application or entity calling the WinINet functions. For our purposes, we can put "QTP_FTP".

The dwAccessType parameter specifies whether we connect directly to a host or whether we use a proxy server for the connection. If we pass the value 1 ( INTERNET_OPEN_TYPE_DIRECT ), we’ll connect directly to the host. If we pass the value 3 ( INTERNET_OPEN_TYPE_PROXY ), we’ll connect via a proxy server. If we pass 0 ( INTERNET_OPEN_TYPE_PRECONFIG ), we’ll connect based on the registry values ProxyEnable, ProxyServer, and ProxyOverride located under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings.

Rather than using the registry settings, we can use the lpszProxy and lpszProxyBypass parameters to provide the proxy server (or servers) and the list of IP addresses or names that should not be routed to the proxy. The basic format for listing a proxy is “protocol=protocol://proxy_name:access_port”. For example, to specify port 21 on Proxy1 as the proxy server, use “ftp=ftp://Proxy1:21” as the lpszProxy. To bypass any host that starts with “nov”, the lpszProxyBypass string would be “nov*”.

Finally, dwFlags is used to indicate various options affecting the behavior of the InternetOpen function. For our example, we’ll pass 0.

Returns a valid handle that the application passes to subsequent WinINet functions. If InternetOpen fails, it returns 0

So, to open an Internet session without using a proxy, our call would be like this:

Const INTERNET_OPEN_TYPE_DIRECT = 1

hInternet = Extern.InternetOpen( _

            "QTP_FTP", INTERNET_OPEN_TYPE_DIRECT, vbNullChar, vbNullChar, 0 )

If hInternet = 0 Then

   Reporter.ReportEvent micFail, "InternetOpen", "Failed to setup environment."

   ExitTest( "InternetOpen" )

End If

If the function call fails, hInternet will be 0. Otherwise, hInternet holds the value of the handle that we’ll need to pass to the InternetConnect function in the next step.

Connect to the host by calling the InternetConnect function.

HINTERNET WINAPI InternetConnect(

  HINTERNET hInternet,

  LPCTSTR lpszServerName,

  INTERNET_PORT nServerPort,

  LPCTSTR lpszUserName,

  LPCTSTR lpszPassword,

  DWORD dwService,

  DWORD dwFlags,

  DWORD dwContext

);

And here’s the QTP-specific declaration for the function call:

Extern.Declare micLong, "InternetConnect", "wininet.dll", "InternetConnectA",

micLong, micString, micInteger, micString, micString, micDWord, micDWord,

micDWord

The first parameter, hInternet is the value of the handle returned by the InternetOpen call.

lpszServerName is the IP address or host name of the FTP server we’re connecting to

nServerPort indicates which port to connect to. For our example, we’ll use the value INTERNET_DEFAULT_FTP_PORT, which indicates the default port (21).

lpszUserName and lpszPassword are used to pass the user name and password, respectively.

The dwService parameter is used to indicate the type of service to access, i.e., HTTP, FTP, etc. We’ll always pass the value of 1 (INTERNET_SERVICE_FTP ), indicating the FTP service.

If we pass the value &H8000000 ( INTERNET_FLAG_PASSIVE ) in the dwFlags parameter, the connection will use passive FTP semantics. Otherwise, as in our example, we can pass 0 to use non-passive semantics.

Finally, dwContext is used to identify the application context when using callbacks. Since we’re not using callbacks and also QTP does not support CallBacks functions, we’ll pass 0.

So here’s the call to connect to the host FTP.MICROSOFT.COM using the anonymous userid:

Const INTERNET_DEFAULT_FTP_PORT = 21

Const INTERNET_SERVICE_FTP = 1

hConnect = Extern.InternetConnect(  _

    hInternet, _

    "ftp.microsoft.com", _

    INTERNET_DEFAULT_FTP_PORT, _

    "anonymous", _

    "daniva1968@hotmail.com", _

    INTERNET_SERVICE_FTP, _

    0, 0  _

)

If hConnect = 0 Then

 Reporter.ReportEvent micFail, "InternetConnect", "Failed to open internet connection."

 ExitTest( "InternetConnect" )

End If

If the function call fails, hConnect will be 0. Otherwise, hConnect holds the value of the handle that we’ll need to pass to the FtpGetFile function in the next step.

Now that we’re connected, we need to call the FtpGetFile function. This function takes care of all of the housekeeping and overhead that comes along with reading a file on an FTP server and storing it locally.

BOOL WINAPI FtpGetFile(

  HINTERNET hConnect,

  LPCTSTR lpszRemoteFile,

  LPCTSTR lpszNewFile,

  BOOL fFailIfExists,

  DWORD dwFlagsAndAttributes,

  DWORD dwFlags,

  DWORD dwContext

);

And here’s the QTP-specific declaration for the function call:

Extern.Declare micInteger, "FtpGetFile", "wininet.dll", "FtpGetFileA", micLong, micString, micString, micInteger, micDWord, micDWord, micDWord

The first parameter, hConnect is the value of the handle returned by the InternetConnect call.

lpszRemoteFile and lpszNewFile are the names of the file on the FTP server and the file to create on the local machine, respectively

The fFailIfExists flag is either False (replace local file) or True (fail if local file already exists).

dwFlagsAndAttributes can be used to specify file attributes for the local file. For our example, we’ll overlook this and just pass 0.

We use the dwFlags parameter to specify 1 ( FTP_TRANSFER_TYPE_ASCII )for transferring the file in ASCII (Type A transfer method) or 2 ( FTP_TRANSFER_TYPE_BINARY ) for transferring the file in Binary (Type I transfer method). Since DIRMAP.TXT is an ASCII text file, we’ll pass the value of 1.

Finally, dwContext is used to identify the application context when using callbacks. Since we’re not using callbacks and also QTP does not support CallBacks functions, we’ll pass 0.

Const FTP_TRANSFER_TYPE_ASCII = 1

remote = "dirmap.txt"

local = "c:\dirmap.txt"

bRetval = Extern.FtpGetFile( _

             hConnection, remote, local, False, 0, FTP_TRANSFER_TYPE_ASCII, 0 )

If Not CBool( bRetVal ) Then

   Reporter.ReportEvent micFail, "FtpGetFile", "Failed to open download file."

   ExitTest( "FtpGetFile" )

End If

If the function call is successful, bRetVal will be True, otherwise, bRetVal will be False.

At this point, the file has been received and now we’re ready to close the connection and session handles using the InternetCloseHandle call.

BOOL WINAPI InternetCloseHandle(

  HINTERNET hInternet

);

And here’s the QTP-specific declaration for the function call:

Extern.Declare micInteger, "InternetCloseHandle", "wininet.dll",

"InternetCloseHandle", micLong

As indicated, this function has only one parameter, hInternet, that is the value of the handle to close or discard. Since, we have handles from the InternetConnection and InternetOpen functions, we’ll need to call this close function twice. In addition, because the InternetConnection handle is dependent on the InternetOpen handle, we’ll need to close these in the reverse order that we created them.

Extern.InternetCloseHandle( hConnection )

Extern.InternetCloseHandle( hInternet )

What about the FTP functions like Put, Rename, Delete, etc? Well, these functions are just as easy.

BOOL WINAPI FtpPutFile(

  HINTERNET hConnect,

  LPCTSTR lpszLocalFile,

  LPCTSTR lpszNewRemoteFile,

  DWORD dwFlags,

  DWORD dwContext

);

And here’s the QTP-specific declaration for the function call:

Extern.Declare micInteger, "FtpPutFile", "wininet.dll", "FtpPutFileA", micLong, micString, micString, micDWord

The first parameter, hConnect is the value of the handle returned by the InternetConnect call.

lpszNewFile and lpszRemoteFile are the names of the file on the local machine and the file to create on the remote host, respectively.

Finally, dwContext is used to identify the application context when using callbacks. Since we’re not using callbacks and also QTP does not support CallBacks functions, we’ll pass 0.

local = "dirmap.txt"

remote = "c:\dirmap.txt"

bRetval = Extern.FtpPutile( hConnection, local , remote, 0 )

If Not CBool( bRetVal ) Then

   Reporter.ReportEvent micFail, "FtpPutFile", "Failed to open download file."

   ExitTest( "FtpPutFile" )

End If

If the function call is successful, bRetVal will be True, otherwise, bRetVal will be False.