|
RFC 959 File Transfer
Protocol
<CRLF> for ASCII, or <NL> for EBCDIC text files, as the
delimiter. If an FTP implementation adopts this technique, it must
be prepared to reverse the transformation if the file is retrieved with
file-structure.
3.1.2.1. FILE
STRUCTURE
File structure is the default to be assumed if the STRUcture command has
not been used.
In file-structure there is no internal structure and the file is
considered to be a continuous sequence of data
bytes.
3.1.2.2. RECORD STRUCTURE
Record structures must be accepted for "text" files (i.e., files with TYPE
ASCII or EBCDIC) by all FTP implementations.
In record-structure the file is made up of sequential records.
3.1.2.3. PAGE STRUCTURE
To transmit files that are discontinuous, FTP defines a page structure.
Files of this type are sometimes known as
"random
access files" or even as "holey files". In these files there is sometimes
other information associated with
the file as a
whole (e.g., a file descriptor), or with a section of the file (e.g., page
access controls), or both.
In FTP, the
sections of the file are called pages.
To provide for various page sizes and associated information, each page is
sent with a page header. The page
header has
the following defined fields:
Header Length
The
number of logical bytes in the page header including this byte. The
minimum header length is 4.
Page Index
The logical page number of this section of the file.
This is not the transmission
sequence number of this page, but the index used to identify this page of
thefile.
RFC 959 File Transfer
Protocol
Data
Length
The
number of logical bytes in the page data. The minimum data length is 0.
Page Type
The
type of page this is. The following page types are defined:
0 =
Last Page
This is used to indicate the end of a paged structured transmission. The
header length must be 4, and the data length must be 0.
1 =
Simple Page
This is the normal type for simple paged files with no page level
associated control information. The header length must be 4.
2 =
Descriptor Page
This type is used to transmit the descriptive information for the file as
a whole.
3 =
Access Controlled Page
This type includes an additional header field for paged files with page
level access control information. The header length must be 5.
Optional
Fields
Further
header fields may be used to supply per page control information, for
example, per page access control.
All fields
are one logical byte in length. The logical byte size is specified by the
TYPE command. See Appendix I for further details and a specific case at
the page structure.
RFC 959 File Transfer
Protocol
be identical to the
version originally transmitted. Conversely, FTP implementations must
return a file identical to the original
if the parameters
used to store and retrieve a file are the same.
3.2. ESTABLISHING
DATA CONNECTIONS
The mechanics of
transferring data consists of setting up the data connection to the
appropriate ports and choosing the parameters
for transfer. Both
the user and the server-DTPs have a default data port. The user-process
default data port is the same as the
control connection
port (i.e., U). The server-process default data port is the port adjacent
to the control connection port (i.e., L-1).
The transfer byte
size is 8-bit bytes. This byte size is relevant only for the actual
transfer of the data; it has no bearing on representation of the data
within a host's file system.
The passive data
transfer process (this may be a user-DTP or a second server-DTP) shall
"listen" on the data port prior to sending a transfer request command.
The FTP request command determines the direction of the data transfer.
The server, upon receiving the transfer request, will initiate the data
connection to the port. When the connection is established, the data
transfer begins between DTP's, and the server-PI sends a
confirming reply to the user-PI.
Every FTP
implementation must support the use of the default data ports, and only
the USER-PI can initiate a change to non-default
ports.
It is possible for
the user to specify an alternate data port by use of the PORT command.
The user may want a file dumped on a TAC
line printer or
retrieved from a third party host. In the latter case, the user-PI sets
up control connections with both server-PI's. One server is then told
(by an FTP command) to "listen" for a connection which the other will
initiate. The user-PI sends one server-PI a PORT command indicating the
data port of the other. Finally, both are sent the appropriate transfer
commands. The exact sequence of commands and replies sent between the
user-controller and the servers is defined in the Section on FTP Replies.
RFC 959 File Transfer
Protocol
is when the
user-DTP is sending the data in a transfer mode that requires the
connection to be closed to indicate EOF. The server
MUST close the data
connection under the following conditions:
1. The server
has completed sending data in a transfer mode that requires a close to
indicate EOF.
2. The server
receives an ABORT command from the user.
3. The port
specification is changed by a command from the user.
4. The control
connection is closed legally or otherwise.
5. An
irrecoverable error condition occurs.
Otherwise the close
is a server option, the exercise of which the server must indicate to the
user-process by either a 250 or 226
reply only.
3.3. DATA CONNECTION
MANAGEMENT
Default Data
Connection Ports: All FTP implementations must support use of the
default data connection ports, and only the
User-PI may
initiate the use of non-default ports.
Negotiating
Non-Default Data Ports: The User-PI may specify a non-default user side
data port with the PORT command. The
User-PI may request
the server side to identify a non-default server side data port with the
PASV command. Since a connection
is defined by the
pair of addresses, either of these actions is enough to get a different
data connection, still it is permitted to do both commands to use new
ports on both ends of the data connection.
Reuse of the Data
Connection: When using the stream mode of data transfer the end of the
file must be indicated by closing the
connection. This
causes a problem if multiple files are to be transfered in the session,
due to need for TCP to hold the connection record for a time out period to
guarantee the reliable communication. Thus the connection can not be
reopened at once.
There are two
solutions to this problem. The first is to negotiate a non-default port.
The second is to use another transfer mode.
RFC 959 File Transfer
Protocol
inherently
unreliable, since one can not determine if the connection closed
prematurely or not. The other transfer modes (Block, Compressed) do not
close the connection to indicate the end of file. They have enough FTP
encoding that the data connection can be parsed to determine the end of
the file.
Thus using these
modes one can leave the data connection open for multiple file transfers.
3.4. TRANSMISSION
MODES
The next
consideration in transferring data is choosing the appropriate
transmission mode. There are three modes: one which
formats the data
and allows for restart procedures; one which also compresses the data for
efficient transfer; and one which passes
the data with
little or no processing. In this last case the mode interacts with the
structure attribute to determine the type of processing. In the
compressed mode, the representation type determines the filler byte.
All data transfers
must be completed with an end-of-file (EOF) which may be explicitly
stated or implied by the closing of the data connection. For files with
record structure, all the end-of-record markers (EOR) are explicit,
including the final one.
For files
transmitted in page structure a "last-page" page type is used.
NOTE: In the rest
of this section, byte means "transfer byte" except where explicitly stated
otherwise.
For the purpose of
standardized transfer, the sending host will translate its internal end of
line or end of record denotation into the
epresentation prescribed by the transfer mode and file structure, and the
receiving host will perform the inverse translation to its internal
denotation. An IBM Mainframe record count field may not be recognized at
another host, so the end-of-record information may be transferred as a
two byte control code in Stream mode or as a
flagged bit in a Block or Compressed mode
descriptor. End-of-line in an ASCII or EBCDIC file with no record
structure should be indicated by <CRLF> or <NL>, respectively. Since
these transformations imply extra work for
some systems,
identical systems transferring non-record structured text files might wish
to use a binary representation and stream
mode for the
transfer.
|
