|
RFC 959 File Transfer
Protocol
The following
transmission modes are defined in FTP:
3.4.1. STREAM MODE
The data is
transmitted as a stream of bytes. There is no restriction on the
representation type used; record structures are allowed.
In a record
structured file EOR and EOF will each be indicated by a two-byte control
code. The first byte of the control code will be all ones, the escape
character. The second byte will have the low order bit on and zeros
elsewhere for EOR and the second low order bit on for EOF; that is, the
byte will have value 1 for EOR and value 2 for
EOF. EOR and EOF may be indicated together on the last byte transmitted
by turning both low order bits on (i.e., the value 3). If a byte of all
ones was intended to be sent as data, it should be repeated in the second
byte of the control code.
If the structure
is a file structure, the EOF is indicated by the sending host closing the
data connection and all bytes are data bytes.
3.4.2. BLOCK MODE
The file is
transmitted as a series of data blocks preceded by one or more header
bytes. The header bytes contain a count field, and descriptor code. The
count field indicates the total length of the data block in bytes, thus
marking the beginning of the next data block (there are no filler bits).
The descriptor
code defines: last block in the file (EOF) last block in the record
(EOR), restart marker (see the Section on Error Recovery and Restart) or
suspect data (i.e., the data being transferred is suspected of errors and
is not reliable).
This last code
is NOT intended for error control within FTP. It is motivated by the
desire of sites exchanging certain types of data (e.g., seismic or weather
data) to send and receive all the data despite local errors (such as
"magnetic tape read errors"), but to indicate in the transmission that
certain portions are suspect). Record structures are allowed in this
mode, and any representation type may be used.
The header
consists of the three bytes. Of the 24 bits of header information, the 16
low order bits shall represent byte count, and the 8 high order bits shall
represent descriptor codes as shown below.
RFC 959 File Transfer Protocol
Block Header
+----------------+----------------+----------------+
|
Descriptor | Byte Count |
| 8
bits | 16 bits |
+----------------+----------------+----------------+
The descriptor
codes are indicated by bit flags in the descriptor byte. Four codes have
been assigned, where each code number is the decimal value of the
corresponding bit in the byte.
Code
Meaning
128 End
of data block is EOR
64 End
of data block is EOF
32
Suspected errors in data block
16 Data
block is a restart marker
With this
encoding, more than one descriptor coded condition may exist for a
particular block. As many bits as necessary
may be flagged.
The restart
marker is embedded in the data stream as an integral number of 8-bit bytes
representing printable characters in the language being used over the
control connection (e.g., default--NVT-ASCII). <SP> (Space, in the
appropriate language) must not be used WITHIN a restart marker.
For example, to
transmit a six-character marker, the following would be sent:
+--------+--------+--------+
|Descrptr|
Byte count |
|code=
16| = 6 |
+--------+--------+--------+
+--------+--------+--------+
| Marker |
Marker | Marker |
| 8 bits | 8
bits | 8 bits |
+--------+--------+--------+
+--------+--------+--------+
| Marker |
Marker | Marker |
| 8 bits | 8
bits | 8 bits |
+--------+--------+--------+
RFC 959 File Transfer
Protocol
3.4.3. COMPRESSED
MODE
There are three
kinds of information to be sent: regular data, sent in a byte string;
compressed data, consisting of replications or filler; and control
information, sent in a two-byte escape sequence. If n>0 bytes (up to 127)
of regular data are sent, these n bytes are preceded by a byte with the
left-most bit set to 0 and the right-most 7 bits containing the number n.
Byte string:
1
7 8 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|
n | | d(1) | ... | d(n) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
^ ^
|---n bytes---|
of data
String of n
data bytes d(1),..., d(n)
Count n must
be positive.
To compress a string of n replications of the data byte d, the following 2
bytes are sent: Replicated Byte:
2
6 8
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1 0|
n | | d |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
A string of n
filler bytes can be compressed into a single byte, where the filler byte
varies with the representation type. If the type is ASCII or EBCDIC the
filler byte is <SP> (Space, ASCII code 32, EBCDIC code 64). If the type
is Image or Local byte the filler is a zero byte.
Filler String:
2 6
+-+-+-+-+-+-+-+-+
|1 1|
n |
+-+-+-+-+-+-+-+-+
RFC 959 File Transfer
Protocol
escape byte (all
zeros) and the second of which contains descriptor codes as defined in
Block mode. The descriptor codes have the same meaning as in Block mode
and apply to the succeeding string of bytes.
Compressed mode
is useful for obtaining increased bandwidth on very large network
transmissions at a little extra CPU cost.
It can be most
effectively used to reduce the size of printer files such as those
generated by RJE hosts.
3.5. ERROR RECOVERY
AND RESTART
There is no
provision for detecting bits lost or scrambled in data transfer; this
level of error control is handled by the TCP.
However, a restart
procedure is provided to protect users from gross system failures
(including failures of a host, an FTP-process, or the underlying network).
The restart
procedure is defined only for the block and compressed modes of data
transfer. It requires the sender of data to insert
a special marker
code in the data stream with some marker information. The marker
information has meaning only to the sender, but must consist of printable
characters in the default or negotiated language of the control connection
(ASCII or EBCDIC).
The marker could
represent a bit-count, a record-count, or any other information by which a
system may identify a data checkpoint. The receiver of data, if it
implements the restart procedure, would then mark the corresponding
position of this marker in the receiving system, and return this
information to the user.
In the event of a
system failure, the user can restart the data transfer by identifying the
marker point with the FTP restart procedure. The following example
illustrates the use of the restart procedure.
The sender of the
data inserts an appropriate marker block in the data stream at a
convenient point. The receiving host marks the
corresponding data
point in its file system and conveys the last known sender and receiver
marker information to the user, either
directly or over
the control connection in a 110 reply (depending on who is the sender).
In the event of a system failure, the user or controller process restarts
the server at the last server marker by sending a restart command with
server's marker code as its argument. The restart command is transmitted
over the control.
RFC 959 File
Transfer Protocol
connection and is
immediately followed by the command (such as RETR, STOR or LIST) which was
being executed when the system
failure occurred.
4. FILE TRANSFER
FUNCTIONS
The communication
channel from the user-PI to the server-PI is established as a TCP
connection from the user to the standard server
port. The user
protocol interpreter is responsible for sending FTP commands and
interpreting the replies received; the server-PI interprets commands,
sends replies and directs its DTP to set up the data connection and
transfer the data. If the second party to the data transfer (the passive
transfer process) is the user-DTP, then itis governed through the internal
protocol of the user-FTP host; if it is a second server-DTP, then it is
governed by its PI on command from the user-PI. The FTP replies are
discussed in the next section. In the description of a few of the
commands in this section, it is helpful to be explicit about the possible
replies.
4.1. FTP COMMANDS
4.1.1. ACCESS
CONTROL COMMANDS
The following
commands specify access control identifiers (command codes are shown in
parentheses).
USER NAME (USER)
The argument
field is a Telnet string identifying the user. The user identification is
that which is required by the server for access to its file system. This
command will normally be the first command transmitted by the user after
the control connections are made (some servers may require this).
Additional identification information in the form of a password and/or an
account command may also be required by some servers. Servers may
allow a new USER command to be entered at any point in order to change the
access control and/or accounting information. This has the effect of
flushing any user, password, and account information already supplied and
beginning the login sequence again. All transfer parameters are unchanged
and any file transfer in progress is completed under the old access
control parameters.
|
