rfc959.txt

RFC 相关的技术文档

      server-FTP process

         A process or set of processes which perform the function of
         file transfer in cooperation with a user-FTP process and,
         possibly, another server.  The functions consist of a protocol
         interpreter (PI) and a data transfer process (DTP).

      server-PI

         The server protocol interpreter "listens" on Port L for a
         connection from a user-PI and establishes a control
         communication connection.  It receives standard FTP commands
         from the user-PI, sends replies, and governs the server-DTP.

      type

         The data representation type used for data transfer and
         storage.  Type implies certain transformations between the time
         of data storage and data transfer.  The representation types
         defined in FTP are described in the Section on Establishing
         Data Connections.




Postel & Reynolds                                               [Page 6]


                                                                        
RFC 959                                                     October 1985
File Transfer Protocol


      user

         A person or a process on behalf of a person wishing to obtain
         file transfer service.  The human user may interact directly
         with a server-FTP process, but use of a user-FTP process is
         preferred since the protocol design is weighted towards
         automata.

      user-DTP

         The data transfer process "listens" on the data port for a
         connection from a server-FTP process.  If two servers are
         transferring data between them, the user-DTP is inactive.

      user-FTP process

         A set of functions including a protocol interpreter, a data
         transfer process and a user interface which together perform
         the function of file transfer in cooperation with one or more
         server-FTP processes.  The user interface allows a local
         language to be used in the command-reply dialogue with the
         user.

      user-PI

         The user protocol interpreter initiates the control connection
         from its port U to the server-FTP process, initiates FTP
         commands, and governs the user-DTP if that process is part of
         the file transfer.




















Postel & Reynolds                                               [Page 7]


                                                                        
RFC 959                                                     October 1985
File Transfer Protocol


   2.3.  THE FTP MODEL

      With the above definitions in mind, the following model (shown in
      Figure 1) may be diagrammed for an FTP service.

                                            -------------
                                            |/---------\|
                                            ||   User  ||    --------
                                            ||Interface|<--->| User |
                                            |\----^----/|    --------
                  ----------                |     |     |
                  |/------\|  FTP Commands  |/----V----\|
                  ||Server|<---------------->|   User  ||
                  ||  PI  ||   FTP Replies  ||    PI   ||
                  |\--^---/|                |\----^----/|
                  |   |    |                |     |     |
      --------    |/--V---\|      Data      |/----V----\|    --------
      | File |<--->|Server|<---------------->|  User   |<--->| File |
      |System|    || DTP  ||   Connection   ||   DTP   ||    |System|
      --------    |\------/|                |\---------/|    --------
                  ----------                -------------

                  Server-FTP                   USER-FTP

      NOTES: 1. The data connection may be used in either direction.
             2. The data connection need not exist all of the time.

                      Figure 1  Model for FTP Use

      In the model described in Figure 1, the user-protocol interpreter
      initiates the control connection.  The control connection follows
      the Telnet protocol.  At the initiation of the user, standard FTP
      commands are generated by the user-PI and transmitted to the
      server process via the control connection.  (The user may
      establish a direct control connection to the server-FTP, from a
      TAC terminal for example, and generate standard FTP commands
      independently, bypassing the user-FTP process.) Standard replies
      are sent from the server-PI to the user-PI over the control
      connection in response to the commands.

      The FTP commands specify the parameters for the data connection
      (data port, transfer mode, representation type, and structure) and
      the nature of file system operation (store, retrieve, append,
      delete, etc.).  The user-DTP or its designate should "listen" on
      the specified data port, and the server initiate the data
      connection and data transfer in accordance with the specified
      parameters.  It should be noted that the data port need not be in


Postel & Reynolds                                               [Page 8]


                                                                        
RFC 959                                                     October 1985
File Transfer Protocol


      the same host that initiates the FTP commands via the control
      connection, but the user or the user-FTP process must ensure a
      "listen" on the specified data port.  It ought to also be noted
      that the data connection may be used for simultaneous sending and
      receiving.

      In another situation a user might wish to transfer files between
      two hosts, neither of which is a local host. The user sets up
      control connections to the two servers and then arranges for a
      data connection between them.  In this manner, control information
      is passed to the user-PI but data is transferred between the
      server data transfer processes.  Following is a model of this
      server-server interaction.

      
                    Control     ------------   Control
                    ---------->| User-FTP |<-----------
                    |          | User-PI  |           |
                    |          |   "C"    |           |
                    V          ------------           V
            --------------                        --------------
            | Server-FTP |   Data Connection      | Server-FTP |
            |    "A"     |<---------------------->|    "B"     |
            -------------- Port (A)      Port (B) --------------
      

                                 Figure 2

      The protocol requires that the control connections be open while
      data transfer is in progress.  It is the responsibility of the
      user to request the closing of the control connections when
      finished using the FTP service, while it is the server who takes
      the action.  The server may abort data transfer if the control
      connections are closed without command.

      The Relationship between FTP and Telnet:

         The FTP uses the Telnet protocol on the control connection.
         This can be achieved in two ways: first, the user-PI or the
         server-PI may implement the rules of the Telnet Protocol
         directly in their own procedures; or, second, the user-PI or
         the server-PI may make use of the existing Telnet module in the
         system.

         Ease of implementaion, sharing code, and modular programming
         argue for the second approach.  Efficiency and independence



Postel & Reynolds                                               [Page 9]


                                                                        
RFC 959                                                     October 1985
File Transfer Protocol


         argue for the first approach.  In practice, FTP relies on very
         little of the Telnet Protocol, so the first approach does not
         necessarily involve a large amount of code.

3.  DATA TRANSFER FUNCTIONS

   Files are transferred only via the data connection.  The control
   connection is used for the transfer of commands, which describe the
   functions to be performed, and the replies to these commands (see the
   Section on FTP Replies).  Several commands are concerned with the
   transfer of data between hosts.  These data transfer commands include
   the MODE command which specify how the bits of the data are to be
   transmitted, and the STRUcture and TYPE commands, which are used to
   define the way in which the data are to be represented.  The
   transmission and representation are basically independent but the
   "Stream" transmission mode is dependent on the file structure
   attribute and if "Compressed" transmission mode is used, the nature
   of the filler byte depends on the representation type.

   3.1.  DATA REPRESENTATION AND STORAGE

      Data is transferred from a storage device in the sending host to a
      storage device in the 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.  DEC TOPS-20s's generally store NVT-ASCII as five 7-bit
      ASCII characters, left-justified in a 36-bit word. IBM Mainframe's
      store NVT-ASCII as 8-bit EBCDIC codes.  Multics stores NVT-ASCII
      as four 9-bit characters in a 36-bit word.  It is desirable to
      convert characters into the standard NVT-ASCII representation when
      transmitting text between dissimilar systems.  The sending and
      receiving sites 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 lengths.  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) to 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



Postel & Reynolds                                              [Page 10]


                                                                        
RFC 959                                                     October 1985
File Transfer Protocol


      that FTP provides for very limited data type representations.
      Transformations desired beyond this limited capability should be
      performed by the user directly.

      3.1.1.  DATA TYPES

         Data representations are handled in FTP by a user specifying a
         representation type.  This type may implicitly (as in ASCII or
         EBCDIC) or explicitly (as in Local byte) define a byte size for
         interpretation which is referred to as the "logical byte size."
         Note that this has nothing to do with the byte size used for
         transmission over the data connection, called the "transfer
         byte size", and the two should not be confused.  For example,
         NVT-ASCII has a logical byte size of 8 bits.  If the type is
         Local byte, then the TYPE command has an obligatory second
         parameter specifying the logical byte size.  The transfer byte
         size is always 8 bits.

         3.1.1.1.  ASCII TYPE

            This is the default type and must be accepted by all FTP
            implementations.  It is intended primarily for the transfer
            of text files, except when both hosts would find the EBCDIC
            type more convenient.

            The sender converts the data from an internal character
            representation to the standard 8-bit NVT-ASCII
            representation (see the Telnet specification).  The receiver
            will convert the data from the standard form to his own
            internal form.

            In accordance with the NVT standard, the <CRLF> sequence
            should be used where necessary to denote the end of a line
            of text.  (See the discussion of file structure at the end
            of the Section on Data Representation and Storage.)

            Using the standard NVT-ASCII representation means that data
            must be interpreted as 8-bit bytes.

            The Format parameter for ASCII and EBCDIC types is discussed
            below.








Postel & Reynolds                                              [Page 11]