|
7. TYPICAL FTP SCENARIO
User at host U wanting to transfer files to/from host S:
In general, the user will communicate to the server via a mediating
user-FTP process. The following may be a typical scenario. The
user-FTP prompts are shown in parentheses, '---->' represents
commands from host U to host S, and '<----' represents replies from
host S to host U.
LOCAL COMMANDS BY USER ACTION INVOLVED
ftp (host) multics<CR> Connect to host S, port L,
establishing control connections.
<---- 220 Service ready <CRLF>.
username Doe <CR> USER Doe<CRLF>---->
<---- 331 User name ok,
need password<CRLF>.
password mumble <CR> PASS mumble<CRLF>---->
<---- 230 User logged in<CRLF>.
retrieve (local type) ASCII<CR>
(local pathname) test 1 <CR> User-FTP opens local file in ASCII.
(for. pathname) test.pl1<CR> RETR test.pl1<CRLF> ---->
<---- 150 File status okay;
about to open data
connection<CRLF>.
Server makes data connection
to port U.
<---- 226 Closing data connection,
file transfer successful<CRLF>.
type Image<CR> TYPE I<CRLF> ---->
<---- 200 Command OK<CRLF>
store (local type) image<CR>
(local pathname) file dump<CR> User-FTP opens local file in Image.
(for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ---->
<---- 550 Access denied<CRLF>
terminate QUIT <CRLF> ---->
Server closes all
connections.
8. CONNECTION ESTABLISHMENT
The FTP control connection is established via TCP between the user
process port U and the server process port L. This protocol is
assigned the service port 21 (25 octal), that is L=21.
APPENDIX I - PAGE STRUCTURE
The need for FTP to support page structure derives principally from
the need to support efficient transmission of files between TOPS-20
systems, particularly the files used by NLS.
The file system of TOPS-20 is based on the concept of pages. The
operating system is most efficient at manipulating files as pages.
The operating system provides an interface to the file system so that
many applications view files as sequential streams of characters.
However, a few applications use the underlying page structures
directly, and some of these create holey files.
A TOPS-20 disk file consists of four things: a pathname, a page
table, a (possibly empty) set of pages, and a set of attributes.
The pathname is specified in the RETR or STOR command. It includes
the directory name, file name, file name extension, and generation
number.
The page table contains up to 2**18 entries. Each entry may be
EMPTY, or may point to a page. If it is not empty, there are also
some page-specific access bits; not all pages of a file need have the
same access protection.
A page is a contiguous set of 512 words of 36 bits each.
The attributes of the file, in the File Descriptor Block (FDB),
contain such things as creation time, write time, read time, writer's
byte-size, end-of-file pointer, count of reads and writes, backup
system tape numbers, etc.
Note that there is NO requirement that entries in the page table be
contiguous. There may be empty page table slots between occupied
ones. Also, the end of file pointer is simply a number. There is no
requirement that it in fact point at the "last" datum in the file.
Ordinary sequential I/O calls in TOPS-20 will cause the end of file
pointer to be left after the last datum written, but other operations
may cause it not to be so, if a particular programming system so
requires.
In fact, in both of these special cases, "holey" files and
end-of-file pointers NOT at the end of the file, occur with NLS data
files.
The TOPS-20 paged files can be sent with the FTP transfer parameters:
TYPE L 36, STRU P, and MODE S (in fact, any mode could be used).
Each page of information has a header. Each header field, which is a
logical byte, is a TOPS-20 word, since the TYPE is L 36.
The header fields are:
Word 0: Header Length.
The header length is 5.
Word 1: Page Index.
If the data is a disk file page, this is the number of that
page in the file's page map. Empty pages (holes) in the file
are simply not sent. Note that a hole is NOT the same as a
page of zeros.
Word 2: Data Length.
The number of data words in this page, following the header.
Thus, the total length of the transmission unit is the Header
Length plus the Data Length.
Word 3: Page Type.
A code for what type of chunk this is. A data page is type 3,
the FDB page is type 2.
|
Word 4: Page Access Control.
The access bits associated with the page in the file's page
map. (This full word quantity is put into AC2 of an SPACS by
the program reading from net to disk.)
After the header are Data Length data words. Data Length is
currently either 512 for a data page or 31 for an FDB. Trailing
zeros in a disk file page may be discarded, making Data Length less
than 512 in that case.
APPENDIX II - DIRECTORY COMMANDS
Since UNIX has a tree-like directory structure in which directories
are as easy to manipulate as ordinary files, it is useful to expand
the FTP servers on these machines to include commands which deal with
the creation of directories. Since there are other hosts on the
ARPA-Internet which have tree-like directories (including TOPS-20 and
Multics), these commands are as general as possible.
Four directory commands have been added to FTP:
MKD pathname
Make a directory with the name "pathname".
RMD pathname
Remove the directory with the name "pathname".
PWD
Print the current working directory name.
CDUP
Change to the parent of the current working directory.
The "pathname" argument should be created (removed) as a
subdirectory of the current working directory, unless the "pathname"
string contains sufficient information to specify otherwise to the
server, e.g., "pathname" is an absolute pathname (in UNIX and
Multics), or pathname is something like "<abso.lute.path>" to
TOPS-20.
REPLY CODES
The CDUP command is a special case of CWD, and is included to
simplify the implementation of programs for transferring directory
trees between operating systems having different syntaxes for
naming the parent directory. The reply codes for CDUP be
identical to the reply codes of CWD.
The reply codes for RMD be identical to the reply codes for its
file analogue, DELE.
The reply codes for MKD, however, are a bit more complicated. A
freshly created directory will probably be the object of a future
CWD command. Unfortunately, the argument to MKD may not always be
a suitable argument for CWD. This is the case, for example, when
a TOPS-20 subdirectory is created by giving just the subdirectory
name. That is, with a TOPS-20 server FTP, the command sequence
MKD MYDIR
CWD MYDIR
will fail. The new directory may only be referred to by its
"absolute" name; e.g., if the MKD command above were issued while
connected to the directory <DFRANKLIN>, the new subdirectory
could only be referred to by the name <DFRANKLIN.MYDIR>.
Even on UNIX and Multics, however, the argument given to MKD may
not be suitable. If it is a "relative" pathname (i.e., a pathname
which is interpreted relative to the current directory), the user
would need to be in the same current directory in order to reach
the subdirectory. Depending on the application, this may be
inconvenient. It is not very robust in any case.
To solve these problems, upon successful completion of an MKD
command, the server should return a line of the form:
257<space>"<directory-name>"<space><commentary>
That is, the server will tell the user what string to use when
referring to the created directory. The directory name can
contain any character; embedded double-quotes should be escaped by
double-quotes (the "quote-doubling" convention).
For example, a user connects to the directory /usr/dm, and creates
a subdirectory, named pathname:
CWD /usr/dm
200 directory changed to /usr/dm
MKD pathname
257 "/usr/dm/pathname" directory created
An example with an embedded double quote:
MKD foo"bar
257 "/usr/dm/foo""bar" directory created
CWD /usr/dm/foo"bar
200 directory changed to /usr/dm/foo"bar
The prior existence of a subdirectory with the same name is an
error, and the server must return an "access denied" error reply
in that case.
CWD /usr/dm
200 directory changed to /usr/dm
MKD pathname
521-"/usr/dm/pathname" directory already exists;
521 taking no action.
The failure replies for MKD are analogous to its file creating
cousin, STOR. Also, an "access denied" return is given if a file
name with the same name as the subdirectory will conflict with the
creation of the subdirectory (this is a problem on UNIX, but
shouldn't be one on TOPS-20).
Essentially because the PWD command returns the same type of
information as the successful MKD command, the successful PWD
command uses the 257 reply code as well.
|
