rfc91.txt

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


RFC 91               A Proposed User-User Protocol         December 1970


   sophisticated, unfortunately.  MULTICS might make it.  Naytheless, I
   hope that is clear that what we want to do, which is what the proto-
   col should reflect, is quite a different question from that of how it
   is to be done in the context of a specific HOST system.  What we want
   to do is, in general, rather independent of the system we are dealing
   with as far as the protocol is concerned, and we should not fail to
   introduce general notions into the protocol just because we are unc-
   ertain as to how they may have to be translated into particular
   implementation practice.

   A PDP-10 IMPLEMENTATION

   Although the following can be implemented as either a set of user
   routines or imbedded in the monitor as UUO's (our first implementa-
   tion will be the former), the latter version will be used for
   descriptive purposes.  The UUO's would be:

        PUTF    CH, E   Put flag

        PUTD    CH, E   Put data

        PUT     CH, E   Put record

        GETFD   CH, E   Get flag or data

        GET     CH, E   Get record

   In the above, "CH" is the logical channel number.  The customary OPEN
   or INIT UUO is used to open the channel.  Standard format user
   buffers are assigned.  However, the ring and buffer headers will be
   used in a nonstandard way, so that data mode 12 is assigned for use
   with Network buffering and file status bit 31 must be on for input.
   (Any of the devices DSK, DTA, MTA, or IMP can be used in this mode.)

   In the Harvard NCP and HOST-HOST protocol implementation, user
   buffers do not correspond directly to messages.  On output, each user
   buffer will be formatted into a message; on input, a message may
   become one or two user buffer loads (128 word buffers are used in
   order to make maximum use of the facilities of the disk service rou-
   tines).











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


   PUTF UUO:

      This UUO places a flag into the output buffer.  The effective
      address is the location of a word:

         XWD operation, count

      In the case of block flags, the count is ignored, since it will be
      computed from the number of bytes actually placed in the buffer
      before the next use of PUTF.  PUTF and PUTD will insert EOM flags
      automatically as each buffer becomes full; if data bytes are
      currently being placed in the buffer by PUTD, it will also insert
      an EOM flag after computing the count for the previous block flag
      in the buffer and place a new block flag of the same type at the
      beginning of the next buffer, after inserting a SIZE flag stating
      the then current byte size.

   PUTD UUO:

      This UUO places data into the output buffer.  The effective
      address is the location of the data byte (if the byte size is less
      than 36) or of the next 36 bit word of data to be placed in the
      buffer.  In the first case, the byte is assumed to be in the low
      order part of the word addresses.  In the second case, the data
      word containing the final bits of the byte contains them in the
      high order part of the word, and the next data byte starts a new
      word in PDP-10 storage.  Thus, for a byte size of 64, two entries
      to PUTD would be used per byte transmitted, the first containing
      36 bits and the second containing 28 bits, left-justified.  This
      strategy allows maximum use of the PDP-10 byte handling instruc-
      tions.

   PUT UUO:

      This UUO places a whole logical record in the output buffer(s).
      The effective address is that of a word:

         IOWD count, location

      A PUTF UUO must have been used to output the proper SIZE flag.
      Thereafter, each use of PUT will output a BLOCK flag, [3] simulate
      a number of calls to PUTD using the IOWD to discover the location
      and size of the user data area, and then output a RS flag to indi-
      cate end of record.







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


      In the case of byte size of less than 36 bits, PUT will use the
      ILDB instruction to pick up bytes to be output by PUTD.  Hence,
      the standard PDP-10 byte handling format is used, and the count
      part of the IOWD is the total byte count, not word count.

      The above UUO'S have both an error return and a normal return.

   GETFD UUO:

      The calling sequence for this UUO is:

         GETFD CH, E
         error return
         whyte flag return
         block flag return
         data return

      The effective address is the location at which the flag or data
      will be returned.  The flag is returned in the same format as for
      PUTF and the data in the same format as for PUTD.  Certain flags
      (NUL, IGNORE, and EOM) will be handled entirely within the UUO and
      will not be reported to the user.  SYS should eventually be han-
      dled this way, but initially will be handled by the user.

   GET UUO:

      The calling sequence for this UUO is:

         GET CH, E
         error return
         end of file return
         end of group return
         normal return

      GET transmits the next logical record to the user, using GETFD
      together with an IOWD in the same format as for PUT.  If the IOWD
      count runs out before end of record, the remainder of the record
      will be skipped.  In any case, the updated IOWD will be returned
      at the effective address of the UUO in order to inform the user
      how much data was transmitted or skipped.

PDP-10 FILE TRANSMISSION:

   Assume that I have a link connected to another PDP-10 and a user
   process there that is listening.  In order to get that process to
   send me a file, the sequence of flags that might be transmitted can





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


   be represented as follows, where the UUO'S executed by me are in the
   left margin, the flags are indented, and the commentary opposite them
   indicates the nature of the data block transmitted:

   PUT F
        CONTROL   Data with OPEN parameters, requesting OPEN
        LABEL     File identification data for LOOKUP
        EOM       Forces message to be transmitted

   GETFD
        STATUS    Status returned by OPEN
        SIZE      Byte size to be used
        LABEL     File retrieval information

   PUTF
        CONTROL   Data requesting INPUT from file
        EOM       Forces request to be transmitted

   GETFD
        STATUS    Status bits returned by INPUT

   GET            Logical record (one file buffer load)
        (loop back to second PUTF, above, for other records)

   Finally, the status information returned by the second GETF indicates
   end of file, and I wind up with the sequence:

   PUTF
        CONTROL   Data requesting a CLOSE
        EOM       Forces transmission

   GETFD
        STATUS    Status bits returned by CLOSE

   In the case I am getting a file, the main loop looks like:

   PUTF
        CONTROL   Data requesting OUTPUT

   PUT            Logical record (one file buffer load)

   PUTF
        EOM       Forces transmission

   GETFD
        STATUS    Status bits returned by OUTPUT





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


   The use of both the record and the flag transmission UUO's is worth
   noting, as well as the use of the EOM flag to force transmission of a
   message when switching between input and output over the link.  PUT
   and GET UUO's are clearly required above for transmission of the CON-
   TROL and LABEL data; I suppressed them for the sake of clarity.

   For this application, the handshaking nature of the transmission of
   CONTROL and STATUS flags are mandatory.  While the protocol would
   permit transmission of a complete file without the handshaking, it
   would be an all or nothing proposition - a single error would neces-
   sitate doing it all over again, presuming that the receiving process
   did not end up in a complete tangle.

   BRIEF DISCUSSION:

   The PDP-10 space required to implement the above protocol is about
   400 instructions, divided equally between the input and the output
   side.  Enough experimental coding has been done to confirm the feasi-
   bility of this basic strategy, taken together with experience with
   implementation and use of the SOS buffering system.

   The above does not touch the question of LOGON protocol, except
   indirectly.  My belief is that it can be accommodated in the frame-
   work of this proposal, but I have not tested this theory as yet.  As
   indicated further above, I would be tempted to handle the matter with
   the SYS flag, given that SYS data is interpreted directly by the sys-
   tem (in our system, we would use the RUN UUO to run the LOGON CUSP,
   which would, in turn handshake using ASCII data over the link).  In
   this way, I think we might be able to dispense with the notion of
   dedicated sockets and the reconnection morass.

   One other point that needs thought is the question of how to handle
   the interrupt on link facility.  Should it have any direct relation
   to the GET/PUT UUO's, or be handled on the side?  I am inclined to
   think that it should be treated _qua_ interrupt of the user process,
   quite independently of the matter of data transmission over the link.
   Some of our current work on the PDP-10 monitor would lend itself
   rather easily to implementation as a true interrupt.


   ENDNOTES*

   1.  A message is that string of bits between any two HOST-HOST
   headers.

   2.  In memory of an attractive, but nonspelling, SDC secretary who
   could not distinguish between black and white, at least during 1957
   and in manuscript form.



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


   3.  PUTF may be used to ouput the block flag, if a different from
   BLOCK is required.




         [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Colin Barrett  9/97   ]











































Mealy                                                          [Page 12]