rfc765.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

            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
            command, as some sites may require an account for login and
            others only for specific access, such as storing files.  In
            the latter case the command may arrive at any time.

            There are reply codes to differentiate these cases for the
            automaton: when account information is required for login,
            the response to a successful PASSword command is reply code
            332.  On the other hand, if account information is NOT
            required for login, the reply to a successful PASSword
            command is 230; and if the account information is needed for
            a command issued later in the dialogue, the server should






                                   22


                                                                        
IEN 149                                                        June 1980
RFC 765                                           File Transfer Protocol