rfc454.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,488 行 · 第 1/5 页
TXT
1,488 行
0 Two lines
1 To first line of the next page
+ No advance
In addition to the above four, there are more characters (defined in
Appendix C, RFC 189) which represent an IBM extension to the ASA
standard.
It should be noted that a serving host need not accept all represen-
tation types and/or byte sizes, but it must inform the user request-
ing an unacceptable type or size of this fact by sending an appropri-
ate reply.
III.C. File Structure and Transfer Modes
The only file structures supported directly in FTP at the present
time are record structures. However, the use of record structures is
not mandatory. A user with no record structure in his file should be
McKenzie [Page 11]
RFC 454 File Transfer Protocol July 1972
able to store and retrieve his file at any HOST. A user wishing to
transmit a record structured file must send the appropriate FTP
'STRU' command (the default assumption is no record structure). A
serving HOST need not accept record structures, but it must inform
the user of this fact by sending an appropriate reply. Any record
structure information in the data stream may subsequently be dis-
carded by the receiver.
All data transfers must end with an EOF. The EOF is defined by the
data transfer mode. For files that have record structures, an EOR is
also defined by the transfer mode. Only the transfer modes and
representation type combinations that have EOR defined may be used
for transfer of files with record structures. Records may be of zero
length but they must be contained in file boundaries. The relation-
ship between files and records is hierarchical but an EOF does not
imply an EOR.
The following data transfer modes are defined in FTP:
1. Stream The file is transmitted as a stream of bytes of the
specified byte size. The EOF is signaled by closing
the data connection. Any representation type and
byte size may be used in the stream mode with file
structure, but use of record structure limits the
type to ASCII or EBCDIC with or without Printfile
format. The convention is that the ASCII character
CR (Carriage Return, Code 15 (octal)) followed by LF
(Line Feed, Code 12 (octal)) indicates an EOR for
ASCII representation type, and the EBCDIC character
NL (New Line, Code 15 (hex)) indicates an EOR for
EBCDIC type. This is the default mode, and it is
recommended that this mode be implemented by all.
2. Text The file is ASCII text transmitted as a sequence of
8-bit bytes in the ASCII representation type, and
optional Printfile format. Record structures are
allowed in this mode. The EOR and EOF are defined by
the presence of special "TELNET-control" codes (,ost
significant bit set to one) in the data stream. The
EOR code is 192 (octal 300, hex CO). The EOF code is
193 (octal 301, hex C1). The byte size for transfer
is 8 bits.
(For ASCII type, text and stream modes are almost identical.)
McKenzie [Page 12]
RFC 454 File Transfer Protocol July 1972
Comparing the two, the advantages of "stream" mode are:
1) The receiver need not scan the incoming bytes.
2) It is usable with all data types.
and the disadvantages are:
1) Closing the data connection under error conditions can be
misconstrued as an EOF in stream mode when in fact the data
transfer was interrupted. In text mode the EOF is sent expli-
citly.
2) If record structure is specified in stream mode then CRLF
implies EOR, and in order for CRLF to be sent as valid data it
must be transformed, e.g., into CR NUL LF or LF CR.
3. Block 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 file block (EOF), last
record block (EOR), restart marker (see Section
III.D), or suspect data (i.e., the data being
transferred is suspected of errors and is not reli-
able). Record structures are allowed in this mode,
and any representation type or byte size may be used.
The header consists of the smallest integral number
of bytes whose length is greater than or equal to 24
bits. Only the _least_ significant 24 bits (right-
justified) of header shall have information; the
remaining most significant bits are "don't care"
bits. 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.
Integral data bytes >= 24
+---------------+---------------+--------------+
| Don't care | Descriptor | Byte Count |
| 0 to 231 bits | 8 bits | 16 bits |
+---------------+---------------+--------------+
McKenzie [Page 13]
RFC 454 File Transfer Protocol July 1972
The following descriptor codes are assigned:
Code Meaning
---- -------
0 An ordinary block of data.
1 End of data block is EOR.
2 End of data block is EOF.
3 Suspected errors in data block.
4 Data block is a restart marker.
In the use of block mode it is possible for two or
more conditions requiring different descriptor codes
(suspected errors and either end of record or end of
file) to exist simultaneously. Such a possibility
may be handled by sending a separate EOR or EOF block
with a zero byte count. (This is allowed by the pro-
tocol.)
The restart marker is embedded in the data stream as
an integral number of 8-bit bytes (representing
printable ASCII characters) right-justified in an
integral number of data bytes greater than 8 bits.
For example if the byte size is 7 bits, the restart
marker byte would be one byte right-justified per two
7-bit bytes as shown below:
Two 7-bit bytes
+----------+------------+
| | Marker Char|
| | 8 bits |
+----------+------------+
For byte size of 16 bits or more, two or more marker
bytes shall be packed right-justified. The end of
the marker may be delimited by the character SP (code
32.). If marker characters do not exactly fit an
integral byte, the unused character slots should con-
tain the ASCII character SP (code 32.). For example,
to transmit a six character marker in a 36-bit byte
size, the following three 36-bit bytes would be sent:
McKenzie [Page 14]
RFC 454 File Transfer Protocol July 1972
+-------------+-------------+---------------+
| Don't care | Descriptor | |
| 12 bits | code=4 | Byte count=2 |
+-------------+-------------+---------------+
+----+---------+---------+--------+---------+
| | Marker | Marker | Marker | Marker |
| | 8 bits | 8 bits | 8 bits | 8 bits |
+----+---------+---------+--------+---------+
+----+---------+---------+--------+---------+
| | Marker | Marker | SP | SP |
| | 8 bits | 8 bits | 8 bits | 8 bits |
+----+---------+---------+--------+---------+
4. Hasp
The file is transmitted as a sequence of 8-bit bytes
in the standard Hasp-compressed data format (document
to be issued by Bob Braden, UCLA). This mode
achieves considerable compression of data for print
files. Record structures are allowed in the Hasp
mode.
The following matrix summarizes the legal combinations of file
transfer parameters. The decimal integers represent legal byte sizes
for each particular STRU-MODE-TYPE-FORM grouping absence of a number
implies illegality. Note that HASP mode is not included since it has
never been defined.
STRU F | R
+-------------------------------+-----+-----+------+
TYPE |\ MODE | | | |
| \ | | | |
| \ S T B | S | T | B |
| FORM +--------+-----+---------+-----+-----+------+
A | U | 8 | 8 | 8 | 8 | 8 | 8 |
| +--------+-----+---------+-----+-----+------+
| P | 8 | 8 | 8 | 8 | 8 | 8 |
----+------+--------+-----+---------+-----+-----+------+
E | U | 8 | | 8 | 8 | | 8 |
| +--------+-----+---------+-----+-----+------+
| P | 8 | | 8 | 8 | | 8 |
----+------+--------+-----+---------+-----+-----+------+
I | U | 1-255 | | 1-255 | | |1-255 |
----+------+--------+-----+---------+-----+-----+------+
L | U | 1-255 | | 1-255 | | |1-255 |
----+------+--------+-----+---------+-----+-----+------+
McKenzie [Page 15]
RFC 454 File Transfer Protocol July 1972
III.D Error Recovery and Restart
There is no provision for detecting bits lost or scrambled in data
transfer. This issue is perhaps handled best at the NCP level where
it benefits most users. However, a restart procedure is provided to
protect user from system failures (such as failure of either HOST,
FTP-process, or the IMP subnet).
The restart procedure is defined only for the block mode 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 ASCII characters. The printable ASCII characters are
defined to be octal codes 41 through 176 (i.e., not including codes 0
through 37 and the characters SP and DEL). 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 pro-
cedure. The following examples illustrate the use of the restart
procedure.
1. When server is the sender of data, the server-FTP process inserts
an appropriate marker block in the data stream at a convenient
data point. The user-FTP process, receiving the data, marks the
corresponding data point in its file system and conveys the last
known sender and receiver marker information to the user. In the
event of system failure, the user or user-FTP process restarts
the server at the last server marker by sending a restart command
with the server's marker code as its argument. The restart com-
mand is transmitted over the TELNET connection and is immediately
followed by the command (such as store or retrieve) which was
being executed when the system failure occurred.
2. When user is the sender of data, the user-FTP process inserts the
appropriate marker block in the data stream. The server-FTP pro-
cess, receiving the data, marks the corresponding data point in
its file system. The server does not store this marker but con-
veys the last known sender and receiver marker information to the
user over the TELNET connections by appropriate reply codes. The
user or the user-FTP process then restarts transfer in a manner
identical to that described in the first example.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?