rfc114.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 956 行 · 第 1/3 页

Network Working Group                                         A. Bhushan
Request for Comments: 114                                MIT Project MAC
NIC: 5823                                                  16 April 1971


                        A FILE TRANSFER PROTOCOL


I. Introduction

   Computer network usage may be divided into two broad categories --
   direct and indirect.  Direct usage implies that you, the network
   user, are "logged" into a remote host and use it as a local user.
   You interact with the remote system via a terminal (teletypewriter,
   graphics console) or a computer.  Differences in terminal
   characteristics are handled by host system programs, in accordance
   with standard protocols (such as TELNET (RFC 97) for teletypewriter
   communications, NETRJS (RFC 88) for remote job entry).  You, however,
   have to know the different conventions of remote systems, in order to
   use them.

   Indirect usage, by contrast, does not require that you explicitly log
   into a remote system or even know how to "use" the remote system.  An
   intermediate process makes most of the differences in commands and
   conventions invisible to you.  For example, you need only know a
   standard set of network file transfer commands for your local system
   in order to utilize remote file system.  This assumes the existence
   of a network file transfer process at each host cooperating via a
   common protocol.

   Indirect use is not limited to file transfers.  It may include
   execution of programs in remote hosts and the transfer of core
   images.  The extended file transfer protocol would facilitate the
   exchange of programs and data between computers, the use of storage
   and file handling capabilities of other computers (possibly including
   the trillion-bit store data computer), and have programs in remote
   hosts operate on your input and return an output.

   The protocol described herein has been developed for immediate
   implementation on two hosts at MIT, the GE645/Multics and the PDP-
   10/DM/CG-ITS (and possibly Harvard's PDP-10).  An interim version
   with limited capabilities is currently in the debugging stage. [1]
   Since our implementation involves two dissimilar systems (Multics is
   a "service" system, ITS is not) with different file systems (Multics
   provides elaborate access controls, ITS provides none), we feel that
   the file transfer mechanisms proposed are generalizable.  In
   addition, our specification reflects a consideration of other file
   systems on the network.  We conducted a survey [2] of network host



Bhushan                                                         [Page 1]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   systems to determine the requirements and capabilities.  This paper
   is a "first cut" at a protocol that will allow users at any host on
   the network to use the file system of every cooperating host.

II.  Discussion

   A few definitions are in order before the discussion of the protocol.
   A file is an ordered set consisting of computer instructions and/or
   data.  A file can be of arbitrary length [3].  A named file is
   uniquely identified in a system by its file name and directory name.
   The directory name may be the name of a physical directory or it may
   be the name of a physical device.  An example of physical directory
   name is owner's project-programmer number and an example of physical
   device name is tape number.

   A file may or may not have access controls associated with it.  The
   access controls designate the users' access privileges.  In the
   absence of access controls, the files cannot be protected from
   accidental or unauthorized usage.

   A principal objective of the protocol is to promote the indirect use
   of computers on the network.  Therefore, the user or his program
   should have a simple and uniform interface to the file systems on the
   network and be shielded from the variations in file and storage
   systems of different host computers.  This is achieved by the
   existence of a standard protocol in each host.

   Criteria by which a user-level protocol may be judged were described
   by Mealy in RFC 91, as involving the notion of logical records,
   ability to access files without program modifications, and
   implementability.  I would add to these efficiency, extendibility,
   adaptability, and provision of error-recovery mechanisms.

   The attempt in this specification has been to enable the reliable
   transfer of network ASCII (7-bit ASCII in 8-bit field with leftmost
   bit zero) as well as "binary" data files with relative ease.  The use
   of other character codes, such as EBCDIC, and variously formatted
   data (decimal, octal, ASCII characters packed differently) is
   facilitated by inclusion of data type in descriptor headings.  An
   alternative mechanism for defining data is also available in the form
   of attributes in file headings.  The format control characters
   reserved for the syntax of this protocol have identical code
   representation in ASCII and EBCDIC.  (These character are SOH, STX,
   ETX, DC1, DC2, DC3, US, RS, GS, and FS.)







Bhushan                                                         [Page 2]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   The notion of messages (the physical blocks of data communicated
   between NCP's) is suppressed herein and that of "logical" records and
   transactions is emphasized.  The data passed by the NCP is parsed
   into logical blocks by use of simple descriptors (code and count
   mechanisms) as described in Section III.  The alternative to count is
   fixed length blocks or standard end-of-file characters (scan data
   stream).  Both seem less desirable than count.

   The cooperating processes may be "daemon" processes which "listen" to
   agreed-upon sockets, and follow the initial connection protocol much
   in the same way as a "logger" does.  We recommend using a single
   full-duplex connection for the exchange of both data and control
   information [4], and using CLS to achieve synchronization when
   necessary (a CLS is not transmitted until a RFNM is received).

   The user may be identified by having the using process send at the
   start of the connection the user's name information (either passed on
   by user or known to the using system) [5].  This user name
   information (a sequence of standard ASCII characters), along with the
   host number (known to the NCP), positively identifies the user to the
   serving process.

   At present, more elaborate access control mechanisms, such as
   passwords, are not suggested.  The user, however, will have the
   security and protection provided by the serving system.  The serving
   host, if it has access controls, can prevent unprivileged access by
   users from other host sites.  It is up to the using host to prevent
   its own users from violating access rules.

   The files in a file system are identified by a pathname, similar to
   the labels described in RFC 76 (Bouknight, Madden, and Grossman).
   The pathname contains the essential information regarding the storage
   and retrieval of data.

   In order to facilitate use, default options should be provided.  For
   example, the main file directory on disk would be the default on the
   PDP-10/ITS, and a pool directory would be the default on Multics.

   The file to be transferred may be a complete file or may consist of
   smaller records.  It may or may not have a heading.  A heading should
   contain ASCII or EBCDIC characters defining file attributes.  The
   file attributes could be some simple agreed-upon types or they could
   be described in a data reconfiguration or interpretation language
   similar to that described in RFC 83 (Anderson, Haslern, and Heffner),
   or a combination.






Bhushan                                                         [Page 3]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   The protocol does not restrict the nature of data in the file.  For
   example, a file could contain ASCII text, binary core image, graphics
   data or any other type of data.  The protocol includes an "execute"
   request for files that are programs.  This is intended to facilitate
   the execution of programs and subroutines in remote host computers
   [6].

III.  SPECIFICATIONS

1. Transactions

   1A.   The protocol is transaction-oriented.  A transaction is defined
         to be an entity of information communicated between cooperating
         processes.

   1B.   Syntax

         A transaction has three fields, a 72-bit descriptor field and
         variable length (including zero) data and filler fields, as
         shown below.  The total length of a transaction is (72 + data +
         filler) bits.

   | <code><filler count><NUL><data count><NUL> |    <data><filler>   |
   | |____||____________||___||__________||___| |    |____________|   |
   |   |         |         |        |       |   |          |          |
   | 24-bits   8-bits    8-bits  24-bits  8-bits|    variable length  |
   | <-------descriptor field 72-bits---------> |<--data and filler-->|
   |                                            |                     |

   1C.   Semantics

         The code field has three 8-bit bytes.  The first byte is
         interpreted as transaction type, the second byte as data type
         and the third byte as extension of data type.

         The filler count is a binary count of bits used as "filler"
         (i.e., not information) at the end of a transaction [7].  As
         the length of the filler count field is 8-bits, the number of
         bits of filler shall not exceed 255 bits.

         The data count is a binary count of the number of data (i.e.,
         information) bits in the data field, not including filler bits.
         The number of data bits is limited to (2^24-1), as there are 24
         bits in the data count field.







Bhushan                                                         [Page 4]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


         The NUL bytes are inserted primarily as fillers in the
         descriptor field and allow the count information to appear at
         convenient word boundaries for different word length machines
         [8].

2.  Transaction Types

   2A.   A transaction may be of the following four basic types:
         request, response, transfer and terminate.  Although large
         number of request and transfer types are defined,
         implementation of a subset is specifically permitted.  Host
         computers, on which a particular transaction type is not
         implemented, may refuse to accept that transaction by
         responding with an unsuccessful terminate.

         The following transaction type codes are tentatively defined:

         Transaction Type                       Transaction Type Code

                                             ASCII   Octal   Hexidecimal

         Request
                 Identify                        I       111     49
                 Retrieve                        R       122     52
                 Store                           S       123     53
                 Append                          A       101     41
                 Delete                          D       104     44
                 Rename                          N       116     4E
                 addname (Plus)                  P       120     50
                 deletename (Minus)              M       115     4D
                 Lookup                          L       114     4C
                 Open                            O       117     4F
                 Close                           C       103     43
                 Execute [9]                     E       105     45

         Response
                 ready-to-receive (rr)           <       074     3C
                 ready-to-send (rs)              >       076     3E

         Transfer
                 complete_file                   *       052
                 heading                         #       043     23
                 part_of_file                    '       054     2C
                 last_part                       .       056     2E

         Terminate
                 successful (pos.)               +       053     2B
                 unsuccessful (neg.)             -       055     2D



Bhushan                                                         [Page 5]

RFC 114                 A FILE TRANSFER PROTOCOL           16 April 1971


   2B.   Syntax

         In the following discussion US, RS, GS, FS, DC1, DC2, and DC3
         are the ASCII characters, unit separator (octal 037), record
         separator (octal 036), group separator (octal 035), file
         separator (octal 034), device control 1 (octal 021), device
         control 2 (octal 022), and device control 3 (octal 023),
         respectively.  These have an identical interpretation in
         EBCDIC.

   2B.1  Requests

         Identify, retrieve, store, append, delete, open, lookup and
         execute requests have the following data field:

                       <path name>

                Rename request has the data field:

                       <path name> GS <name>

                Addname and deletename requests have the data field:

                       <path name> GS <filenames>

         where pathname [10], name and filenames have the following
         syntax (expressed in BNF, the metalanguage of the ALGOL 60
         report):

         <pathname> ::= <device name>|<name>|<pathname>US<name>
         <device name> ::= DC1<name>

         <name> ::= <char> | <name> <char>