rfc91.txt

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

Network Working Group                                    George H. Mealy
Request for Comments: 91                              Harvard University
                                                       December 27, 1970


                     A PROPOSED USER-USER PROTOCOL

INTRODUCTION:

   There are many good reasons, and maybe one or two bad ones, for
   making it appear that communication over the Network is only a
   special case of input/output -- at least as far as user programming
   is concerned.  Thus, for instance, the Harvard approach toward
   implementing the HOST-HOST protocol and Network Control Program
   treats each link as a "logical device" in PDP-10 terminology.
   Setting up a connection is similar to local device assignment, and
   communication over a link will make use of the standard system
   input/output UUO's.  This makes it possible to use existing programs
   in conjunction with the Network without modification -- at least if
   other PDP-10's are being dealt with.

   This takes us only so far, however.  The notion of a "logical device"
   does not exist on the PDP-10; it does on the IBM 360 (I am speaking
   here at the level of the operating system -- user program interface).
   Furthermore, in the absence of a Network standard requiring fixed
   representations for integers, reals, etc. (which I would oppose), any
   pair of user processes must arrive at a local agreement, and one or
   both must assume the burden of data conversion where necessary.  Any
   standard protocol should allow such agreements to be given expression
   and should accommodate at least the minimum of control information
   that will allow such agreements to function in practice.  Finally, we
   must note that the IMP-IMP and HOST-HOST protocols do not provide for
   a check that an action requested by a user process is actually
   accomplished by the other processes; this type of issue has always
   been regarded as subject to treatment at the USER-USER protocol
   level.

   This proposal is intended to face the above three types of issue only
   to a certain extent.  I can best explain that extent by stating the
   criteria I would use to judge any USER-USER protocol proposal:











Mealy                                                           [Page 1]

RFC 91               A Proposed User-User Protocol         December 1970


   1.   The notion of a (logical) _record_ should be present, and the
        notion of a _message_ should be suppressed. (To a FORTRAN pro-
        grammer, that which is written using one WRITE statement with no
        accompanying FORMAT is a record; to an OS/360 machine language
        programmer, PUT writes a record).

   2.   It should be possible to so implement the protocol in HOST sys-
        tems and/or library routines that now existing user programs can
        access files anywhere in the Network without program modifica-
        tion. (Initially, at least, this ability must be restricted to
        HOST systems of the same type).

   3.   The protocol should be implementable (not necessarily imple-
        mented) in any HOST system at the SVC or UUO level.  Specific
        knowledge of the characteristics of the other HOST involved
        should be unnecessary.

   It should be noted that the above imply that some user programs must
   be aware of the nature of the other HOST -- at least in each case
   where the second criterion fails.  As we make progress in (or give up
   on) the cases where the failure now occurs, the burden of accommodat-
   ing system differences will shift toward implementation in protocols
   (i.e., the HOST systems) or, by default, in user programs.

   Quite clearly, any proposal initiated today should be suspect as to
   the extent to which it "solves" ultimate problems.  How ambitious to
   be is strictly a matter of taste.  At this stage, I prefer to try
   something which I believe can be used by all of us (and, hence, is
   worth doing), goes a reasonable distance towards solving our short-
   range problems, is easy to do, and offers hope of viability in the
   long range view.  In the following, I intend to describe the proposal
   itself with, I hope, proper motivational arguments for its pieces.  I
   will then sketch the specific implementation we at Harvard are making
   for the PDP-10 and describe how we intend to apply it in the specific
   case of storage of files on other PDP-10's in the Network.

USER-USER PROTOCOL (PROPOSAL)

   The following protocol is intended to apply to the data bits in mes-
   sages between the end of the marking bits and the beginning of the
   padding bits. _The present IMP-IMP and HOST-HOST protocols are unaf-
   fected by this proposal_.

   The general principle is that each segment (this is not a technical
   term) of data is preceded by control information specifying its
   nature and extent.  The basic scheme has been evolved from that used
   in the SOS buffering system (see the papers in JACM, April 1959 and
   especially that by O.R. Mock).



Mealy                                                           [Page 2]

RFC 91               A Proposed User-User Protocol         December 1970


   Our point of view is that a link is a carrier of information.  Infor-
   mation is carried in segments of a fixed maximum length called _mes-
   sages_ [1].  That this is so is an accident, from the user's point of
   view; when he wishes to transmit a contiguous stream of data, he will
   in general, segment it in a different (from the IMP-IMP or HOST-HOST
   protocol view) manner -- we will call his segment a _record_.  It
   should be clear that this is entirely analogous between the notion of
   (physical) _block_ and (logical) record.  On the side, file storage
   systems also make use of control and status information; we will
   also.

   At the USER-USER protocol level, all information transmitted over the
   link is a sequence of flags followed by (possibly null) data blocks.

   The general format will be:

        OPERATION     COUNT     DATA

   The OPERATION field is always present and is four bits long.  The
   COUNT field, when present, gives the number of data bytes following
   in the data block.  The byte size is set by the last preceding SIZE
   flag (in most cases).  The byte may be between zero and 255 bits long
   (Yes, Virginia, zero is zero even when you have a System/360).  The
   OPERATION field and the COUNT field (when present) are called the
   flag and the data bytes (when present) the data block.  Flags fol-
   lowed by data blocks (even when null due to a zero count) are called
   block flags, and other flags are called whyte [2] flags.

   It is to be noted that, since the SIZE flag sets the byte size for
   the following blocks, byte size may be set at that "natural" for the
   sending or for the receiving HOST, depending on local agreement
   between the sending and receiving processes.  It is specifically
   required that a SIZE flag appear in each message prior to any block
   flag (except the ASCII flag); the SIZE flag may be introduced on a
   default basis by the routine(s) implementing the protocol and is
   intended partially as a means of detecting certain classes of error.

   The COUNT field is 8 bits in length (except in the EOM flag, where it
   is 16 bits long).  The flags are as follows:

   Whyte Flags:

      0 - NUL             No operation (consider next flag)
      1 - RS              Record Separator (end of record)
      2 - GS              Group Separator (end of group)
      3 - FS              File Separator (end of file)
      4 - ESC             Escape to local convention for flags
      5 -                 (reserved for later assignment)



Mealy                                                           [Page 3]

RFC 91               A Proposed User-User Protocol         December 1970


      6 - EOM N           End of Message (N is total bit count)
      7 - SIZE N          Byte size is N bits
      8 - IGNORE N        Ignore following data bits

   Block Flags:
       9 - SYS N          N bytes of data for receiving HOST system
      10 - CONTROL N      N bytes of control data follow
      11 - STATUS N       N bytes of status data follow
      12 - LABEL N        N bytes of identification data follow
      13 - KEY N          N bytes of key data follow
      14 - ASCII N        N (8-bit) bytes of ASCII data follow
      15 - BLOCK N        N bytes of data follow

   I have already mentioned the requirement for SIZE.  Absence of the
   SIZE flag in any message containing block flags (except ASCII) is a
   definite error.  EOM is partially another error-checking device and
   partially a device for bypassing the padding conundrum.  A user pro-
   gram should never see EOM on input; the user may write an EOM to
   force transmission.  EOM delimits the end of the useful information
   in the message and restates the total number of bits in the message,
   starting with the first bit following the marking and ending with the
   last bit of the EOM count field, to check possible loss of informa-
   tion.  This is a check against errors in the IMP-HOST electrical
   interface and in the HOST mushyware.  EOM must appear at the end of
   each messager, unless ESC has apeared.

   ESC is intended as a (hopefully) unused escape hatch, for nonuse by
   those installations and/or applications wishing to avoid using more
   than four bits of the USER-USER protocol on any link.  For instance,
   it may be desired to use a link as a bit stream, ignoring even mes-
   sage boundaries.  If and when anarchists can achieve local agreement,
   more power to them!

   NUL and IGNORE are intended to be space fillers, in case it is help-
   ful to make the first bit of the subsequent data block occur on a
   convenient address boundary. (An especially helpful HOST interrupt
   routine might even paste a combination of NUL and IGNORE over the
   marking bits when receiving a message -- in which case, their bit
   count should be transmitted on to the GET routines to correct the EOM
   bit count check).  The separator operations introduce the notions of
   logical record, group, and file.  Specifically, there is no require-
   ment that a record be contained entirely within a message or that
   only a single record be contained in a message!  In addition, there
   is no requirement that only one file be transmitted during a connec-
   tion.  For instance, a user might wish to use a link to transmit a
   collection of rountines, and then do something else with the link.





Mealy                                                           [Page 4]

RFC 91               A Proposed User-User Protocol         December 1970


   By local agreement, then, a single routine might consist of a number
   of records forming a group, the whole collection might form a file,
   and the link might remain connected after the FS flag is received.

   The interpretation of the various block flags is similarly open to
   local agreement.  The two flags intended to convey pure data are
   ASCII and BLOCK; the difference between them is only (as far as the
   protocol is concerned) that the byte size is implicit for ASCII (8
   bits) and explicit for BLOCK (the count field of the next preceding
   SIZE flag).  Beyond this, however, the semantic content of the block
   following ASCII is governed by the current standards for ASCII;
   EBCDIC information may not be transmitted in an ASCII block!!

   CONTROL and STATUS are intended for communication of control informa-
   tion between user processes, and the interpretation of their accom-
   panying data blocks is open to local agreement.  Generically, CONTROL
   means "try to do the following" and STATUS means "but I feel this
   way, doctor."  A CONTROL flag will prompt a returned STATUS flag,
   sooner or later, or never.  LABEL is intended for use in identifying
   the following unit(s) of data, at the file or group level.  Again,
   the specific interpretation is a matter of local agreement.  KEY is
   intended to mimic the notion of address or key -- this is at the
   record, data item, or even physical storage block level.  For the
   familiar with PDP-10 system and/or OS/360, the following parallels
   are offered for guidance:

   USER-USER protocol      OS/360            PDP-10
   __________________      ______            ______

     CONTROL               OPEN              OPEN

                           CLOSE             CLOSE

     LABEL                 DSCB              File retrieval information

     KEY                   KEY               USETI/USETO argument

     CONTROL               READ              IN/INPUT

                           WRITE             OUT/OUTPUT

                           ALLOCATE ?        ENTER

                           OPEN ?            LOOKUP

     STATUS                ?                 GETSTS





Mealy                                                           [Page 5]

RFC 91               A Proposed User-User Protocol         December 1970


   The "?" notations above indicate lack of a very direct parallel.  It
   is worth noting that the OS/360 GET and PUT have direct parallels in
   any implementation of the USER-USER protocol that embodies the notion
   of record; our implementation of the protocol will lead to introduc-
   tion of this notion for all PDP-10 input/output involving disc and
   tape storage, as well as IMP communication.

   If I knew the MULTICS terminology, I could extend the set of paral-
   lels above with more precision.  Although my terminology has been
   drawn from systems with explicit input/output imperatives, I wish to
   emphasize that this setup in intended to handle control and data com-
   munication in general; MULTICS is a system in which the classical
   distinction between external and internal storage is blurred (from
   the user's point of view) in a manner I wish it blurred in the USER-
   USER protocol.  I offer SYS with only slight trepidation.  The gen-
   eral notion is that one should be able to communicate directly with a
   foreign HOST rather than via a foreign user process as its intermedi-
   ary.  SYS is like a UUO or SVC, but for the foreign HOST's consump-
   tion rather than my HOST's.  From the HOST's point of view, the prob-
   lem in implementation is in establishing a process context record
   unconnected with any local user process.  This, however, is strongly
   associated with our current LOGON conundrum.  On the PDP-10, for
   instance, users are more or less identified with local teletype
   lines, and any link is not one of those! Hence, subterfuge is neces-
   sary to let a foreign user log on.  OS/360 is as (actually, more)
   perverse in its own way.

   The process of logging a foreign process onto my local system is not
   (except possibly for MULTICS) a simple matter of having a special
   (!!)  user job present which is responsible for doing it.  When and
   if anything else is possible, the HOST must provide a system instruc-
   tion (UUO or SVC or whatever) that gives the requisite information
   establishing a process independent in all senses of the process that
   made the request.  Otherwise, self-protection mechanisms which are
   reasonable for any system will make us all much more interdependent
   that we wish.  To do this, there must exist in every system a UUO/SVC
   that does the right thing (ATTACH, but forget me).  If this is true,
   then the LOGON process over the Network is tantamount to issuance of
   a foreign UUO/SVC by another node in the Network.  I see no reason-
   able way around this.  If that is the case, then SYS N is the kind of
   flag to use to convey the requisite data.  If that is so, then it is
   only reasonable to let SYS convey a request for any OS instruction at
   the user program-operating system interface level!

   The practical questions of implementation are something else! In the
   case of the PDP-10, I can pretty well see how to turn a SYS into
   either a LOGON request to execute a monitor command or UUO (would
   that they were the same) as the case might be.  OS/360 is more



Mealy                                                           [Page 6]