rfc354.txt

RFC 的详细文档！

    3) the socket or byte size specification is changed.

    4) any of the TELNET connections are closed.

    5) an irrecoverable error condition.

    It should be noted that two simultaneous data connections
(for send and receive) may exist. It is a server option, however, to
close the data connection after each instance of file transfer.

III.B Data Representation and Storage

    Data is transferred from a storage device in sending HOST to
a storage device in receiving HOST. Often it is necessary to perform
certain transformations on the data because data storage representations
in the two systems are different. For example, NVT-ASCII has different
data storage representations in different systems. PDP-10's generally
store NVT-ASCII as five 7-bit ASCII characters, left justified in a 36
bit word. 360's store NVT-ASCII as 8-bit EBCDIC codes. Multics stores
NVT-ASCII as four 9-bit characters in a 36-bit word. It may desirable to
convert characters into the standard NVT-ASCII representation when
transmitting text between disimilar systems. The sending and receiving
site would have to perform the necessary transformations between the
standard representation and their internal representations.

    A different problem in representation arises when
transmitting binary data (not character codes) between HOST systems with
different word length. it is not always clear how the sender should send
data, and the receiver store it. For example, when transmitting 32-bit
bytes from a 32-bit word-length system to a 36-bit word-length system,
it may be desirable (for reasons of efficiency and usefulness) o store
the 32-bit bytes right justified in a 36-bit word in the latter system.
In any case, the user should have the option of specifying data
representation and transformation functions. It should be noted that FTP
provides for very limited data types reprentations.  Transformations
desired beyond this limited capability should be performed by the user
directly or via the use of the Data Reconfiguration Service (DRS, RFC
#138, NIC #6715). Additional representation types may be defined later
if there is a demonstrable need.



                                                                [Page 7]

The File Transfer Protocol                                  July 8, 1972


    Data representations are handled in FTP by a user specifying
a representation type. The type may also specify a fixed transfer byte
size. For example in ASCII and Print File representations, the transfer
byte size must be 8 bits. Only in the Image and Local Byte
representations the byte size specified by the BYTE command is to be
used. The following data representation types are currently defined in
FTP:

1. ASCII            The sender converts data form its internal
                    character representation to the standard
                    ARPANET ASCII form. The receiver converts
                    the data from the standard form to its own
                    internal form. The data is transferred in
                    the standard form. The transfer byte size
                    must be 8 bits. This type would be used for
                    transfer of text files. This is be default
                    type, and it is recommended that this type be
                    implemented by all.

2. Image            The sender transforms data from contiguous
                    bits to bytes for transfer. The receiver
                    transforms the bytes into bits, storing them
                    contiguously independent of the byte size
                    chosen for data transfer. Typical uses for
                    the Image type are transfer of executable
                    programs between like machines, and transfer
                    of binary (non-text) data. It is recommended
                    that this type be implemented by all for some
                    byte size preferably including the 8 bit byte
                    size.

3. Local Byte       This representation allows for efficient
                    storage, use, and retrieval of data. The
                    mann in which data is to be transformed
                    depends on the byte size for data transfer,
                    and the particular HOST being used. The
                    transformation scheme for different byte size
                    is to be well publicized b all server sites.
                    This transformation shall be invertible
                    (i.e., if a file is stored using a certain
                    transfer byte size, an identical file must be
                    retrievable using the same byte size and
                    representation type). It is the user's
                    responsibility to keep track of the
                    representation type and byte size used for
                    his transfer. Typical uses of the Local Byte
                    type are in efficient storage and retrieval
                    of files, and transfer of structured binary



                                                                [Page 8]

The File Transfer Protocol                                  July 8, 1972


                    data. This type may be identical to the
                    image type for byte size which are integral
                    multiples of or factors of the computer word
                    length-

4. Print File-      The server site will transform the ASCII
   ASCII            file in a form suitable for printing at the
                    server site. The byte size must be 8 bits.
                    The transformation may not be invertible.
                    This type is different from ASCII in that
                    TABs, FFs and other ASCII format effector
                    characters may be replaced by SPs, LFs, and
                    other substitute characters. The print file
                    conversions are to be well publicized by all
                    server sites. This type would be used when
                    the file is destined for an ASCII printer.
                    This type in some systems may be identical to
                    the ASCII type. It is recommended that this
                    type be implemented by all.

5. EBCDIC Print     The server site will transform the EBCDIC
   File             file into a form suitable for printing at the
                    server site. The byte size must be 8 bits.
                    the transformation may not be invertible.
                    This type would be used when the file is
                    destined for an EBCDIC printer. Only systems
                    which use EBCDIC for their internal character
                    representation need accept this type.

    It should be noted that a serving HOST need not accept all
representation types and/or byte size, but it must inform the user of
the fact by sending an appropriate 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 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 discarded by the
receiver.






                                                                [Page 9]

The File Transfer Protocol                                  July 8, 1972


    All data transfer 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 or files with record structures. Records may be of zero length
but they must be contained in file boundaries. The relationship between
files and records is heirarchical and an EOF implies 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 signalled by
                    closing the data connection. Any representation
                    type and byte size may be used in the stream mode
                    but record structures are possible only with the
                    ASCII representation type. The convention is that
                    the ASCII character CR (Carriage Return, Code 13.)
                    followed by LF (Line Feed, Code 10.) Indicates an
                    EOR in stream mode and ASCII representation 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 sequence of
                    8-bit bytes in the ASCII representation type.
                    Record structures are allowed in this mode. The
                    EOR and EOF are defined by the presence of special
                    "TELNET-control" codes (most significant bit set
                    of one) in the data stream. The EOR code is 192
                    (octal 300, hex C0). The EOF code os 193 (octal
                    301, hex C1). The byte size for transfer is 8
                    bits.

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 reliable). Record structures are allowed in
                    this mode, and any representation type or byte
                    size may be used. The header consists of integral
                    number of bytes whose length is greater than or
                    equal to 24 bits. Only the least significant 24
                    bits (right-jusified) of header shall have



                                                               [Page 10]

The File Transfer Protocol                                  July 8, 1972


                    information, other must significant bits must be
                    zero. 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


                    | Must be Zero  | Descriptor    | Byte Count    |
                    | 0 to 231 bits |   8 bits      |    16 bits    |

                    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.

                    The restart marker is imbedded in the data stream
                    as integral number of 8-bit bytes (representing
                    printable ASCII characters) right-justified in
                    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 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
                    no exactly fit an integral byte, the unused
                    character slots should contain 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:

                    |   Zero    |  Descriptor  |               |
                    |   12 bits |  code=4      | Byte count=2  |




                                                               [Page 11]

The File Transfer Protocol                                  July 8, 1972


                    |    | 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.

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 teh 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 codes 33. through 126. (i.e., not including codes 0. through 31.
and the characters SP and DEL). The marker could represent a bit-count,a
record-count, or any other information by wich 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 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
coressponding 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






                                                               [Page 12]

The File Transfer Protocol                                  July 8, 1972


last server marker by sending a restart command with the server's marker
code at its argument.  The restart command 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
occured.

    2. When user is the sender of data, the user-FTP process
inserts the appropriate marker block in the data stream. The server-FTP
process receiving the data, marks the corresponding data point in its
file system. The server does not store this marker but conveys 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.

IV. FILE TRANSFER FUNCTIONS

    The TELNET connections on which FTP commands and replies are
transmitted, are initiated by the user-FTP process via an ICP to a
standard server socket. FTP commands are then transmitted from user to
server, and replies are transmitted from server to user.  The user file
transfer functions invoive sending the FTP commands, interpreting the
replies received and transferring data over the data connection in the
specified manner. The server file transfer functions involve accepting