📄 rfc765.txt
字号:
The following transmission modes are defined in FTP:
STREAM
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 file structure, the EOF is indicated by
the sending Host closing the data connection and all bytes
are data bytes.
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 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
17
June 1980 IEN 149
File Transfer Protocol RFC 765
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.
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 TELNET
connection (e.g., default--NVT-ASCII). <SP> (Space, in the
appropriate language) must not be used WITHIN a restart
marker.
18
IEN 149 June 1980
RFC 765 File Transfer Protocol
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 |
+--------+--------+--------+
COMPRESSED
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:
19
June 1980 IEN 149
File Transfer Protocol RFC 765
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 |
+-+-+-+-+-+-+-+-+
The escape sequence is a double byte, the first of which is
the 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.
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 TELNET connection (ASCII or EBCDIC).
The marker could represent a bit-count, a record-count, or any
20
IEN 149 June 1980
RFC 765 File Transfer Protocol
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 TELNET 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 TELNET
connection and is immediately followed by the command (such as
RETR, STOR or LIST) which was being executed when the system
failure occurred.
FILE TRANSFER FUNCTIONS
The communication channel from the user-PI to the server-PI is
established by a TCP connection from the user to a 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 it
is 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.
FTP COMMANDS
ACCESS CONTROL COMMANDS
The following commands specify access control identifiers
(command codes are shown in parentheses).
21
June 1980 IEN 149
File Transfer Protocol RFC 765
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 TELNET 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 account.
PASSWORD (PASS)
The argument field is a TELNET string identifying the user's
password. This command must be immediately preceded by the
user name command, and, for some sites, completes the user's
identification for access control. Since password
information is quite sensitive, it is desirable in general
to "mask" it or suppress typeout. It appears that the
server has no foolproof way to achieve this. It is
therefore the responsibility of the user-FTP process to hide
the sensitive password information.
ACCOUNT (ACCT)
The argument field is a TELNET string identifying the user's
account. The command is not necessarily related to the USER
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -