rfc122.txt

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

   unauthorized retrieval and/or modification.  When a file is created,
   the user may associate with it a _modification password_ and/or an
   _access password_.  Thereafter, SMFS will demand that the appropriate
   password be supplied before the file is modified or retrieved,
   respectively.  Since SMFS protects each file independently against
   unauthorized modification and retrieval, a group of users can be
   given access to a file while a single individual retains the
   exclusive right to modify it.  If no password is defined for a
   particular type of reference to a file, then such references are
   unrestricted.  Passwords have the same attributes as filenames --
   same length restrictions and same character sets.

   Because of the manner in which SMFS writes files onto secondary
   storage, it must insure that while one user is modifying a file, no
   other user is simultaneously either modifying or retrieving the same
   file.  This requirement is effected by a mechanism internal to SMFS
   and hence transparent to users, with the exception that when a user
   attempts to retrieve or modify a file currently being modified by
   another user, SMFS will delay action upon the request until the
   current modification is complete.  There is no restriction on the
   number of users which may concurrently retrieve the same file.

V.   Primitive File Operations

   SMFS recognizes and will execute the following primitive file
   operations:

V.A.  Allocate File (ALF)

   SMFS regards the reservation of filename, the assignment of
   passwords, and the reservation of secondary storage as an operation
   distinct from that of transmitting the file's contents.  The
   operation is called _file allocation_, abbreviated ALF.  In
   allocating a file, the user specifies the filename to be assigned to
   it, the access password (if any), and the estimated size of the file
   in bits.  SMFS checks the proposed filename to insure that it doesn't
   duplicate that of an existing file.  SMFS also checks to insure that
   it has sufficient secondary storage available to accommodate the new




J. White                                                        [Page 6]

RFC 122                Simple-Minded file System              April 1971


   file.  If both requirements are met, SMFS allocates the file; the
   filename is reserved, secondary storage is reserved, and the password
   information is recorded.

   In reserving secondary storage for a file, SMFS adds its estimate of
   its overhead in storing the file to the user-declared size of the
   file.  In general, the user should slightly over-estimate the size of
   his file at allocation.  SMFS allocates a fixed amount of storage on
   the basis of that estimate, an amount which cannot be increased
   later.  SMFS's actual overhead in storing a file is a function of the
   manner in which the contents of the file are transmitted by the user.
   The overhead is minimal when the file is transmitted in a single
   series of operations (see Section VI) and increases as the number of
   operations increases.  It is the overhead associated with single-
   series transmission that SMFS adds to the file size specified by the
   user to determine the amount of storage to allocate.  Hence, for
   multiple-series transmission, the overhead will have been
   underestimated.

V.B.  Update File (UDF)

   The operation of transmitting part or all of a previously allocated
   file's contents for storage by SMFS is called _updating_ the _file_
   (UDF).  The user specifies the filename of the file to be updated,
   the modification password if required, the amount of data in bits to
   be added to the file, and finally the data itself.  SMFS locates the
   file on secondary storage, checks the password for validity, if
   appropriate, and adds the data to the file.  SMFS considers the
   update complete when either the specified number of bits have been
   extracted from the input stream and stored, or when the user
   terminates transmission by closing the connection.

   The data transmitted in a UDF operation is _concatenated_ to the
   current contents of the file.  Boundaries between updates are
   transparent to the user when the file is retrieved.  Hence, for
   example, the contents of a file might be transmitted to SMFS in two
   distinct UDF operations, and later retrieved in a single RTF
   operation (see Section V.D.).  The user should view a file stored
   with SMFS as a potentially very long bit string which may be
   transmitted to SMFS in any number of variable-length _segments_, and
   is retrievable in any number of variable-length segments, with the
   manner of segmentation chosen during retrieval independent of that
   selected during the updating process.

   The user may optionally request that SMFS 'remember' the manner in
   which a file was updated, i.e., along with the data, store sufficient
   information to reconstruct segment boundaries at retrieval time.
   Such a file is said to be _formatted_.  In retrieving a formatted



J. White                                                        [Page 7]

RFC 122                Simple-Minded file System              April 1971


   file, the user, rather than requesting that SMFS transmit the next
   'n' bits of the file as he would do for an unformatted file (see
   Section V.D.), requests that SMFS transmit the next segment of the
   file; it is then SMFS's responsibility to supply the length of the
   segment.  Hence, the notion of a _logical record_ is introduced.

   Of course, since the user may format the contents of a file in any
   way he chooses, he can embed record-length information in the data
   itself.  Hence, the user can implement a record structure in a way
   that's transparent to SMFS.  This scheme, however, requires during
   retrieval that, for each logical record retrieved, the user fetch
   first the length field and then, using the length as an operand,
   fetch the data itself.  In this kind of arrangement, the retrieval
   rate is apt to suffer.  However, by allowing SMFS knowledge of
   logical-record boundaries, the feedback loop is effectively shortened
   (SMFS being closer to the file); hence, the potential exists for an
   increased retrieval rate.

   If the user intends that a file be formatted, he must so specify in
   every update and every retrieve operation referencing that file.
   SMFS in no way flags a file to indicate that it is formatted.  Hence,
   if the user invokes the option during retrieval without having done
   so when the file was stored, results will be erroneous.  Furthermore,
   if an update of a formatted file is terminated before the bit count
   for the operation is exhausted (i.e., because the user closed the
   connection), retrieval results will again be erroneous.

V.C.  Replace File (RPF)

   The replace-file (RPF) operation is identical to UDF, except that the
   new file segment, rather than being concatenated to the existing
   file, _replaces_ the entire contents of the file.  The previous
   contents of the file are lost, and the new segment becomes the only
   segment in the file.

   RPF may be used to rewrite an existing file.  If the rewritten file
   is to contain just a single segment, that segment may be transmitted
   to SMFS in an RPF operation.  Otherwise, the first segment of the new
   file must be transmitted in an RPF operation, and all succeeding
   segments in UDF operations.  Alternately, a dummy (bit count of zero)
   RPF operation may be inserted before the first real segment is
   transmitted; all segments of the file may then be transmitted in UDF
   operations.








J. White                                                        [Page 8]

RFC 122                Simple-Minded file System              April 1971


V.D.  Retrieve File (RTF)

   The operation which retrieves all or part of a file's contents is
   called file retrieval (RTF).  The user specifies the filename of the
   file to be retrieved, the access password if required, and the amount
   of data in bits to be fetched from the file.  SMFS locates the file
   on secondary storage, checks the password for validity (if
   appropriate), and copies the bit count and the requested file segment
   into the output stream.  SMFS considers the retrieval complete when
   either the requested number of bits have been placed in the output
   stream, or when the contents of the file are exhausted.  In this
   latter case, SMFS closes the connection to signal end-of-data to the
   user.

   Successive RTF operations referencing the same file cause successive
   segments of the file to be transmitted, provided that the operations
   are juxtaposed in the input stream (however, NOP's may be
   interspersed anywhere in the input stream).  When a series of RTF
   operations referencing a particular file is broken by an operation
   referencing another file, or by a different type of operation
   involving the same file, the next RTF operation designating the
   original file will cause the _first_ segment of that file to be
   transmitted.  The manner in which the user segments a file for a
   series of retrieve operations need bear no relationship to the
   segmentation scheme employed when the file was updated, nor to that
   employed in previous retrievals.

   If the user elected to have his file formatted by SMFS, he should
   re-invoke the option in the RTF operation, in which case SMFS will
   supply the length of the segment, and place both it and the segment
   itself into the output stream.

V.E.  Space File (SPF)

   Files stored with SMFS are sequential in organization.  That is the
   n+1th segment of the file cannot be retrieved without first
   processing the nth segment.  The user may, however, upon occasion,
   wish to retrieve only selected segments of a file.  This he could do,
   effectively, by retrieving each segment of the file and flushing
   those with which he was currently unconcerned.  To avoid needless
   Network traffic, SMFS provides a mechanism for flushing file segments
   locally.  The operation is called _spacing_ a file (SPF).  It is
   identical to RTF with the exception that transmission of data (but
   not bit count) is suppressed.  SPF operations may be freely inserted
   anywhere within a series of RTF operations designating a particular
   file, with the desired results.





J. White                                                        [Page 9]

RFC 122                Simple-Minded file System              April 1971


V.F.  Delete File (DLF)

   A file may be deleted at any time after allocation.  The user
   specifies the filename of the file to be deleted and the modification
   password if required.  SMFS locates the file on secondary storage,
   checks the password for validity (if appropriate), and, if the
   password is correct, deletes the file.  The filename is made
   available for reassignment, and the secondary storage allocated to
   the file is reclaimed by SMFS.  The contents (if any) of the file are
   lost.

V.G.  Rename File (RNF)

   A file stored with SMFS may be renamed at any time after allocation.
   The user specifies the current filename of the file to be renamed,
   the modification password if any, and the proposed new filename.
   SMFS locates the file on secondary storage, checks the password for
   validity (if appropriate), and assures that the proposed new filename
   is not already assigned to another file.  If these requirements are
   met, the file is renamed, and all subsequent references to the file
   must be by the newly-assigned filename.

   RNF provides a means for protecting a file that must be rewritten in
   its entirety against failures in the Net, or in the sending or
   receiving host.  The strategy is as follows.  Allocate a new file,
   assigning it some temporary name.  Transmit the revised file contents
   in one more UDF and/or RPF operations.  Then delete the original file
   and, using RNF, replace the newly-created file's temporary filename
   with that of the original file.

V.H.  File no Operation (FNO)

   FNO is a dummy operation which is provided for use in terminating a
   series of RTF operations.  Should the user desire to retrieve the
   contents of a file twice in succession, he may do so with a series of
   RTF/SPF operations, followed by a FNO followed by a second series of
   RTF/SPF operations.  Each RTF/SPF operation in the first series will
   retrieve/flush the next segment of the file.  The first operation of
   the second string, since it _is_ the first of a string, will, as
   explained in Section V.D., retrieve/flush the _first_ segment of the
   file.  The remaining operations in the second string will, of course
   retrieve/flush the 2nd, 3rd, etc., segments of the file.  Hence, the
   contents of the file are transmitted twice.  FNO, when it terminates
   such a string of operations, effectively repositions the user to the
   first segment of the file.

   FNO may appear anywhere within the input stream.




J. White                                                       [Page 10]

RFC 122                Simple-Minded file System              April 1971


V.I.  No Operation (NOP)

   This operation is provided _solely_ to aid the user in formatting the
   input stream, and is discarded without further processing whenever it
   is encountered.  In particular, a NOP embedded in a series of RTF
   operations does not terminate the string as FNO does.


VI.  Input Stream Format

   The input stream shall consist of a contiguous string of commands to
   SMFS.  A command type is defined for each of the primitive file
   operations of Section V. Each command has the following general
   format:

  8     16                                              32
 ______________//______//_________//__________//_________________//__
|    |     |        |        |            |         |         |      |
| OP |     |        | ACCESS |MODIFICATION|   NEW   |         |      |
|CODE|FLAGS|FILENAME|PASSWORD|  PASSWORD  | FILENAME|BIT COUNT| DATA |
|____|_____|___//___|__//____|____//______|___//____|_________|__//__|


   where the lengths of fixed-length fields have been indicated in bits.