lenny@icus.ICUS.COM (Lenny Tropiano) (08/09/90)
I've been asked several times if the access to Ohio State will be upgraded
from ftp and uucp only to ftp, uucp and e-mail. My response has been, no,
since I don't have access to login to cheops.cis.ohio-state.edu and set
things up like that. Basically Karl Kleinpaste has been generous enough to
let us use a small portion of OSU-CIS' disk space for retrieval of these
archives. The other thing is that sending anything large over mail is
a bit of a waste of net-bandwidth and it does cost the intervening neighbors
dollars ...
Well, I did a little research, and sure enough there is something out there
that is call BITFTP at Princeton University. BITFTP resides on PUCC.BITNET
and is a mail-type server to Internet FTP sites. It works well, I tried it.
Depending on the load of the machine, the network, and how many other jobs
ahead of you, your return "item" gets sent back to you via e-mail rather
promptly. Note what I'm about to show you is something that could be
generalized and used for *any* ftp-able site.
**** PLEASE DON'T ABUSE THIS **** Since the network is mostly a collection
of people working together and offering their machine as a site on the network,
unnecessary (excessive) stress on non-leaf nodes won't be appreciated --
by anyone. What I'm getting down to is use your own judgement when grabbing
items that are excessive in size. The archive-server does split them up
into smaller chunks (uuencoded) for transport over mail but it still has
an impact. (ie. Don't grab things like FIXDISK2.0 or gnu-emacs, g++, etc..
use your own common sense...)
The procedure is fairly simple. All you need to do is compose a message
with the appropriate FTP commands enclosed, and mail it to BITFTP@PUCC.BITNET.
The message should be in the form (for the cheops archives):
FTP cheops.cis.ohio-state.edu UUENCODE
USER anonymous
BINARY
cd pub/att7300
Then you should include commands like:
(for current directories)
ls -l -or-
ls -lt
And to snarf files ...
get README.Z (this will grab README.Z and return it to you
uuencoded by e-mail)
If all goes well within 12 to 24 hours you should receive at least part1
of any of your requests. Don't keep sending requests if you don't receive
it right away, otherwise you'll be in jeopardy of receiving multiple copies
of something, again a big waste.
Once the mail arrives, you process it with the 'uudecode' program and you'll
be on your way. Since it's coming from a non-UNIX machine, filename
conversions take place. (eg. xxxxxxx.cpio.Z --> XXXXXXX.CPIOZ) Rename
them as needed after they are uudecoded.
Good luck all!
-Lenny
======
[When you send the word 'help' to BITFTP@PUCC.BITNET, you'll receive this]
BITFTP -- Princeton BITNET FTP Server
BITFTP provides a mail interface to the FTP portion
of the IBM TCP/IP product ("FAL") running on the
Princeton VM system, to allow BITNET/NetNorth/EARN users
to ftp files from sites on the Internet.
BITFTP currently accepts requests only via RFC822-format
mail, IBM NOTE-format mail, PROFS-format messages, or
files with no headers at all. BITFTP currently returns
the requested files as NETDATA-format files or as mail files
containing UUENCODED data. If you specify "UUENCODE" or
"NETDATA" on your "FTP" command, BITFTP will attempt to
use that format. If you do not specify the format, BITFTP
will attempt to select the appropriate format for your node.
BITFTP attempts to send NETDATA-format files through the gateway
from EARN into Janet via the NIFTP facility at Rutherford Lab.
If BITFTP sends you a file you cannot read, THE FIRST THING
TO DO is to make sure that you specified ASCII if the file
should contain textual material or that you specified BINARY
if the file should contain binary data, executable programs,
tar files, or the like. VMS users should specify BINARY F 512
and should use RECEIVE/BINARY to receive the NETDATA-format
binary files BITFTP sends them.
If BITFTP sends you a uuencoded file that you cannot
uudecode, the first thing to do is to translate all occurrences of
0x7E in the file to 0x5E and then try uudecoding again. (Some
gateways are changing 5Es to 7Es when the files pass through them.)
To use BITFTP, send mail containing your ftp commands to
"BITFTP@PUCC". The first command to BITFTP must be "FTP"
or "HELP".
The recommended syntax for ftp requests is:
FTP hostname NETDATA --or-- FTP hostname UUENCODE
USER username password
<other ftp subcommands>
QUIT
After the hostname on the FTP command, you may specify
"UUENCODE" or "NETDATA" to tell BITFTP the format in which
you wish to receive files.
(If the username is "anonymous", no password is required;
BITFTP will use your userid and nodeid as the password.)
Note that on many systems passwords are case-sensitive;
that is, the password may be required to be in lower case
or mixed case or upper case. (The same is true of directory
and file names.)
The following is an example of an ftp request:
FTP f.ms.uky.edu NETDATA
USER anonymous
CD /pub/msdos/Games
DIR
BINARY
GET robotron.arc msdos.robotron
QUIT
To request a list of some of the hosts that allow anonymous ftp,
send BITFTP mail or a message containing only the command "FTPLIST".
Note that there is no guarantee that BITFTP can access
all the hosts in this list.
BITFTP implements a subset of the ftp subcommands provided
in the IBM TCP/IP and uses the same syntax. Therefore, you
may find it useful to obtain the "IBM TCP/IP for VM Command
Reference Manual", IBM order number GC09-1204.
The currently supported subcommands are:
ACCT -- to send host-dependent account information.
format: ACCT account-information
ASCII -- to change the file transfer type to ASCII.
format: ASCII
BINARY -- to change the file transfer type to image.
format: BINARY <FIXED record-len> <VARIABLE>
CD -- to change the working directory.
format: CD directory
CLOSE -- to disconnect from the foreign host.
format: CLOSE
DIR -- to get a list of directory entries.
format: DIR
EBCDIC -- to change the file transfer type to EBCDIC
format: EBCDIC
GET -- to get a file from the foreign host.
format: GET foreignfile <localfile>
If you specify "localfile", it must be in
the forms "filename.filetype" or "filename",
and the filename and filetype may each be no
more than 8 characters long and may not contain
periods.
LOCSTAT -- to display local status information.
format: LOCSTAT
LS -- to list the files in a directory.
format: LS <name>
PWD -- to print the working directory.
format: PWD
QUIT -- to disconnect from the foreign host.
format: QUIT
STATUS -- to retrieve status information from a foreign host.
format: STATUS <name>
SYSTEM -- to get the name of the foreign host's operating system.
format: SYSTEM
TYPE -- to specify Image, ASCII, or EBCDIC file transfer.
format: TYPE <I|A|E>
The files you request will be sent to you in NETDATA format or
UUENCODED inside mail files.
You will also receive a mail file containing a log of your
ftp session. In that mail file, entries prefixed by ">" are
your original commands; those prefixed by ">>" are your
commands as interpreted by BITFTP and passed to TCPIP; those
prefixed by ">>>" are your commands as interpreted by TCPIP and
passed to the remote host; those prefixed by "<<<" are messages
from the remote host; and those prefixed by ">>>>" are completion
messages from BITFTP.
If BITFTP is unable to connect to the host you specify,
it will send you mail after the first attempt, but will keep
trying at intervals over three days. The only additional mail
files you will receive will be when the connection is made
successfully or when BITFTP gives up after three days.
The load on BITFTP is often very heavy, and network
backlogs are often so great that it may take several days
for a file to get to you once BITFTP sends it, so please be
patient and don't send multiple requests for the same file.
If your system allows you to send interactive messages, you
can inquire about BITFTP's backlog by sending the query
"How are you?", e.g., on a VM system:
TELL BITFTP AT PUCC How are you?
This service is currently under development and is far from
complete. Current plans for improvements include:
1. Acknowledgments via MSG when mail is received and when
processing has been completed.
2. A much more complete HELP facility.
Questions about BITFTP and suggestions for improvements
should be directed to Melinda Varian, MAINT@PUCC on BITNET or
MAINT@pucc.princeton.edu on the Internet.
The author gratefully acknowledges the use of the FTP
SUBCOM interface written by David Nessl, the SENDJANI EXEC
written by Alan Flavell, the uuencoding utility written by
John Fisher, and the RFC822 parsing routine written by Eric
Thomas. NOTE: If you have any complaints or suggestions
about the way any of these routines work in BITFTP, please
send them to MAINT@PUCC (Melinda Varian), not to the authors.
--
| Lenny Tropiano ICUS Software Systems lenny@icus.ICUS.COM |
| {ames,pacbell,decuac,sbcs,hombre,rayssd}!icus!lenny attmail!icus!lenny |
+------ ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752 ------+