FTP (File Transfer Protocol) is the primary method of transferring files over the Internet. On many systems, it's also the name of the program that implements the protocol. Given proper permission, it's possible to copy a file from a computer in South Africa to one in Los Angeles at very fast speeds (on the order of 510K per second). This normally requires either a user id on both systems or a special configuration set up by the system administrator(s).
There is a good way around this restriction--the anonymous FTP service. It essentially will let anyone in the world have access to a certain area of disk space in a non-threatening way. With this, people can make files publicly available with little hassle. Some systems have dedicated entire disks or even entire computers to maintaining extensive archives of source code and information. They include gatekeeper.dec.com (Digital), wuarchive.wustl.edu (Washington University in Saint Louis), and archive.cis.ohio-state.edu (The Ohio State University).
The process involves the "foreign" user (someone not on the system itself) creating an FTP connection and logging into the system as the user 'anonymous', with an arbitrary password:
Name (foo.site.com:you): anonymous Password: jm@south.america.org
Custom and netiquette dictate that people respond to the Password: query with an email address so that the sites can track the level of FTP usage, if they desire. (See Section 2.1 [Addresses], page 11 for information on email addresses).
The speed of the transfer depends on the speed of the underlying link. A site that has a 9600bps SLIP connection will not get the same throughput as a system with a 56k leased line (see Section 1.5 [The Physical Connection ] for more on what kinds of connections can exist in a network). Also, the traffic of all other users on that link will affect performance. If there are thirty people all FTPing from one site simultaneously, the load on the system (in addition to the network connection) will degrade the overall throughput of the transfer.
Lest we forget, the Internet is there for people to do work. People using the network and the systems on it are doing so for a purpose, whether it be research, development, whatever. Any heavy activity takes away from the overall performance of the network as a whole.
The effects of an FTP connection on a site and its link can vary; the general rule of thumb is that any extra traffic created detracts from the ability of that site's users to perform their tasks. To help be considerate of this, it's highly recommended that FTP sessions be held only after normal business hours for that site, preferably late at night. The possible effects of a large transfer will be less destructive at 2 a.m. than 2 p.m. Also, remember that if it's past dinner time in Maine, it's still early afternoon in California-- think in terms of the current time at the site that's being visited, not of local time.
While there have been many extensions to the various FTP clients out there, there is a de facto "standard" set that everyone expects to work. For more specific information, read the manual for your specific FTP program. This section will only skim the bare minimum of commands needed to operate an FTP session.
The actual command to use FTP will vary among operating systems; for the sake of clarity, we'll use 'FTP' here, since it's the most general form.
There are two ways to connect to a system--using its hostname or its Internet number. Using the hostname is usually preferred. However, some sites aren't able to resolve hostnames properly, and have no alternative. We'll assume you're able to use hostnames for simplicity's sake. The form is ftp somewhere.domain [See Section 1.1 "Domains", for help with reading and using domain names] (in the example below, somewhere.domain is ftp.uu.net). You must first know the name of the system you want to connect to. We'll use 'ftp.uu.net' as an example. On your system, type:
ftp ftp.uu.net
(the actual syntax will vary depending on the type of system the connection's being made from). It will pause momentarily then respond with the message
Connected to ftp.uu.net.
and an initial prompt will appear:
220 uunet FTP server (Version 5.100 Mon Feb 11 17:13:28 EST 1991) ready.
Name (ftp.uu.net:jm):
to which you should respond with:
anonymous
220 uunet FTP server (Version 5.100 Mon Feb 11 17:13:28 EST 1991) ready.
Name (ftp.uu.net:jm): anonymous
The system will then prompt you for a password; as noted previously, a good response is your email address:
331 Guest login ok, send ident as password.
Password: jm@south.america.org
230 Guest login ok, access restrictions apply.
ftp>
The password itself will not echo. This is to protect a user's security when he or she is using a real account to FTP files between machines. Once you reach the ftp> prompt, you know you're logged in and ready to go.
At the 'ftp>' prompt, you can type a number of commands to perform various functions. One example is 'dir'--it will list the files in the current directory. Continuing the example from above:
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 3116
drwxr-xr-x 2 721512 Nov 21 1988 .forward
-rw-rw-r-- 1 711 0 Jun 23 1988 .hushlogin
drwxrwxr-x 2 021512 Jun 4 1990 Census
drwxrwxr-x 2 0120 512 Jan 8 09:36 ClariNet
....etc etc......
-rw-rw-r-- 1 714 42390 May 20 02:24 newthisweek.Z
....etc etc......
-rw-rw-r-- 1 7142018887 May 21 01:01 uumap.tar.Z
drwxrwxr-x 2 761024 May 11 10:58 uunet-info
226 Transfer complete.
5414 bytes received in 1.1 seconds (4.9 Kbytes/s)
ftp>
The file 'newthisweek.Z' was specifically included because we'll be using it later. Just for general information, it happens to be a listing of all of the files added to UUNET's archives during the past week. The directory shown is on a machine running the Unix operating system-- the dir command will produce different results on other operating systems (e.g. TOPS, VMS, et al.). Learning to recognize different formats will take some time. After a few weeks of traversing the Internet, it proves easier to see, for example, how large a file is on an operating system you're otherwise not acquainted with.
With many FTP implementations, it's also possible to take the output of dir and put it into a file on the local system with
ftp> dir n* outfilename
the contents of which can then be read outside of the live FTP connection; this is particularly useful for systems with very long directories (like ftp.uu.net). The above example would put the names of every file that begins with an 'n' into the local file outfilename.
At the beginning of an FTP session, the user is in a "top-level" directory. Most things are in directories below it (e.g. '/pub'). To change the current directory, one uses the cd command. To change to the directory 'pub', for example, one would type
ftp> cd pub
which would elicit the response
250 CWD command successful.
Meaning the "Change Working Directory" command ('cd') worked properly. Moving "up" a directory is more system-specific--in Unix use the command 'cd ..', and in VMS, 'cd {-}.
The actual transfer is performed with the get and put commands. To get a file from the remote computer to the local system, the command takes the form:
ftp> get filename
where filename is the file on the remote system. Again using ftp.uu.net as an example, the file 'newthisweek.Z' can be retrieved with
ftp> get newthisweek.Z
200 PORT command successful.
150 Opening ASCII mode data connection for newthisweek.Z (42390 bytes).
226 Transfer complete.
local: newthisweek.Z remote: newthisweek.Z
42553 bytes received in 6.9 seconds (6 Kbytes/s)
ftp>
The section below on using binary mode instead of ASCII will describe why this particular choice will result in a corrupt and subsequently unusable file.
If, for some reason, you want to save a file under a different name (e.g. your system can only have 14-character filenames, or can only have one dot in the name), you can specify what the local filename should be by providing get with an additional argument
ftp> get newthisweek.Z uunet-new
which will place the contents of the file 'newthisweek.Z' in 'uunet-new' on the local system. The transfer works the other way, too. The put command will transfer a file from the local system to the remote system. If the permissions are set up for an FTP session to write to a remote directory, a file can be sent with
ftp> put filename
As with get, put will take a third argument, letting you specify a different name for the file on the remote system.
In the example above, the file 'newthisweek.Z' was transferred, but supposedly not correctly. The reason is this: in a normal ASCII transfer (the default), certain characters are translated between systems, to help make text files more readable. However, when binary files (those containing non- ASCII characters) are transferred, this translation should not take place. One example is a binary program--a few changed characters can render it completely useless.
To avoid this problem, it's possible to be in one of two modes--ASCII or binary. In binary mode, the file isn't translated in any way. What's on the remote system is precisely what's received. The commands to go between the two modes are:
ftp> ascii
200 Type set to A. (Note the A, which signifies ASCII mode.)
ftp> binary
200 Type set to I. (Set to Image format, for pure binary transfers.)
Note that each command need only be done once to take effect; if the user types binary, all transfers in that session are done in binary mode (that is, unless ascii is typed later).
The transfer of 'newthisweek.Z' will work if done as:
ftp> binary
200 Type set to I.
ftp> get newthisweek.Z
200 PORT command successful.
150 Opening BINARY mode data connection for newthisweek.Z (42390 bytes).
226 Transfer complete.
local: newthisweek.Z remote: newthisweek.Z
42390 bytes received in 7.2 seconds (5.8 Kbytes/s)
Note: The file size (42390) is different from that done in ASCII mode (42553) bytes; and the number 42390 matches the one in the listing of UUNET's top directory. We can be relatively sure that we've received the file without any problems.
The commands mget and mput allow for multiple file transfers using wildcards to get several files, or a whole set of files at once, rather than having to do it manually one by one. For example, to get all files that begin with the letter 'f', one would type
ftp> mget f*
Similarly, to put all of the local files that end with .c:
ftp> mput *.c
Rather than reiterate what's been written a hundred times before, consult a local manual for more information on wildcard matching (every DOS manual, for example, has a section on it). Normally, FTP assumes a user wants to be prompted for every file in a mget or mput operation. You'll often need to get a whole set of files and not have each of them confirmed--you know they're all right. In that case, use the prompt command to turn the queries off.
ftp> prompt
Interactive mode off.
Likewise, to turn it back on, the prompt command should simply be issued again.
A group of people at McGill University in Canada got together and created a query system called archie. It was originally formed to be a quick and easy way to scan the offerings of the many anonymous FTP sites that are maintained around the world. As time progressed, archie grew to include other valuable services as well.
The archie service is accessible through an interactive telnet session, email queries, and command-line and X-window clients. The email responses can be used along with FTPmail servers for those not on the Internet. (See [FTP-by-Mail Servers], page 77, for info on using FTPmail servers.)
Currently, archie tracks the contents of over 800 anonymous FTP archive sites containing over a million files stored across the Internet. Collectively, these files represent well over 50 gigabytes of information, with new entries being added daily.
The archie server automatically updates the listing information from each site about once a month. This avoids constantly updating the databases, which could waste network resources, yet ensures that the information on each site's holdings is reasonably up to date.
To access archie interactively, telnet to one of the existing servers. [See Chapter 5 "Telnet" for notes on using the telnet program.]
They include:
At the login: prompt of one of the servers, enter 'archie' to log in. A greeting will be displayed, detailing information about ongoing work in the archie project; the user will be left at a 'archie>' prompt, at which he may enter commands. Using 'help' will yield instructions on using the 'prog' command to make queries, 'set' to control various aspects of the server's operation, et al. Type 'quit' at the prompt to leave archie. Typing the query 'prog vine.tar.Z' will yield a list of the systems that offer the source to the X-windows program vine; a piece of the information returned looks like:
Host ftp.uu.net (137.39.1.9)
Last updated 10:30 7 Jan 1992
Location: /packages/X/contrib
FILE rw-r--r-- 15548 Oct 8 20:29 vine.tar.Z
Host nic.funet.fi (128.214.6.100)
Last updated 05:07 4 Jan 1992
Location: /pub/X11/contrib
FILE rw-rw-r-- 15548 Nov 8 03:25 vine.tar.Z
There are two main-stream archie clients, one called (naturally enough) 'archie', the other 'xarchie' (for X-Windows). They query the archie databases and yield a list of systems that have the requested file(s) available for anonymous FTP, without requiring an interactive session to the server. For example, to find the same information you tried with the server command 'prog', you could type
% archie vine.tar.Z
Host athene.uni-paderborn.de
Location: /local/X11/more_contrib
FILE -rw-r--r-- 18854 Nov 151990 vine.tar.Z
Host emx.utexas.edu Location: /pub/mnt/source/games
FILE -rw-r--r-- 12019 May 7 1988 vine.tar.Z
Host export.lcs.mit.edu
Location: /contrib
FILE -rw-r--r-- 15548 Oct 9 00:29 vine.tar.Z
Note that your system administrator may not have installed the archie clients yet; the source is available on each of the archie servers, in the directory 'archie/clients'. Using the X-windows client is much more intuitive--if it's installed, just read its man page and give it a whirl. It's essential for the networked desktop.
Users limited to email connectivity to the Internet should send a message to the address 'archie@archie.mcgill.ca' with the single word help in the body of the message. An email message will be returned explaining how to use the email archie server, along with the details of using FTPmail. Most of the commands offered by the telnet interface can be used with the mail server.
In addition to offering access to anonymous FTP listings, archie also permits access to the whatis description database. It includes the names and brief synopses for over 3,500 public domain software packages, datasets and informational documents located on the Internet.
Additional whatis databases are scheduled to be added in the future. Planned offerings include listings for the names and locations of online library catalog programs, the names of publicly accessible electronic mailing lists, compilations of Frequently Asked Questions lists, and archive sites for the most popular Usenet newsgroups. Suggestions for additional descriptions or locations databases are welcomed and should be sent to the archie developers at 'archie-l@cs.mcgill.ca'.
Go to the next chapter.
Go to the previous chapter.
Go to the Table of Contents.
Go to the Glossary.