rfc333.txt

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

|                 MSP    |       |  MSP                  |
|       TABLE    _____   |       |   _____  TABLE        |
|             +-|_ _ _|  |  "IN" |  |_ _ _|              |
|             | |_ _ _|<-|----------|_ _ _|<-\           |RECEIVE
|             | |_ _ _|  |       |  |_ _ _|   \       <--|(from=S
|             |          |       |             \         |  to=R
|            _V_         |       |              \        | rend=RNDZ)
|    BUFFER |   |        |       |             (PROCESS) |
|           |___|        |       |             (   R   ) |
+------------------------+       +-----------------------+

   Host RNDZ now notices that the "OUT" from Host SND and the "IN" from
   R at RCV match one another and thus Host RNDZ takes three actions:

      1. Sends an "IN to Host SND (from-port-id = S, to-port-id = R,
         rendezvous-Host = RNDZ).

      2. Sends an "OUT" and the buffered data to Host RCV (from-port-id
         = S, to-port-id = R, rendezvous-Host =RNDZ)

      3. Clears the entry from its table.

   HOST SND                                           HOST RCV
   +------------------+        +------------+         +-------------+
   |                  |        |   TABLE    |         |             |
   |   TABLE  ___     |  "IN"  |    ___     |  "OUT"  |   ___  TABLE|
   |         |___|    |        |   |___|    |  + DATA |  |_ _|      |
   |         |___|<---|--------|---|___|----|---------|->|_ _|      |
   |         |___|    |        |   |___|    |         |  |_ _|      |
   | ( S )            |        +------------+         |        ( R )|
   |                  |          HOST RNDZ            |             |
   +------------------+                               +-------------+

   Host RCV gets the "OUT" and DATA and finds the matching entry in its
   table.  It gives the DATA to process R and clears the entry from its
   table.

   Host SND gets an "IN" which matches an entry in his table and clears
   that entry.  This message serves as a combined acknowledgement and go
   ahead which can be passed along to process S.

   The transmission is now complete.



Bressler, et al.            Experimentation                     [Page 6]

RFC 333          MESSAGE SWITCHING PROTOCOL EXPERIMENT          May 1972


   By both, one, or neither of the sender and receiver processes
   specifying a remote rendezvous Host, four important different kinds
   of transmissions can be made to take place.  These are illustrated in
   the following four figures.  In the figures crossed or parallel
   dotted lines are used to indicate rendezvous.  The site of the
   "crossed rendezvous" is the important difference between types of
   transmission illustrated in figures.  Circles indicate processes.
   Rectangles are rendezvous tables.

   The figures also show "(IN)" and "(OUT)" messages being passed into
   the processes.  The parentheses are used to indicate that the "IN"
   and "OUT" are only CONCEPTUALLY passed into the processes.  What
   actually happens is implementation dependent.  The process might be
   awakened and be given no further information if it blocked when
   issuing the SEND or RECEIVE.  The process might be interrupted and
   passed some information such as the to-port-id from the IN or the
   from-port-id of the OUT.  The process might actually be passed the
   complete IN or OUT message.

      ------         _________           ------
     (      )       |         |         (      )
     (      ) SEND  |         | RECEIVE (      )
     (      )------>|--+  +---|<--------(      )
     (      )       |   \/    |         (      )
     (      ) (IN)  |   /\    |  (OUT)  (      )
     (      )<------|--+   +--|-------->(      )
     (______)       |_________| +DATA   (______)

     |<------------- Host K ------------------>|

               A Rendezvous at the Sender's Host


      ----         _______               ______          ----
     (    )       |       |             |      |        (    )
     (    ) SEND  |       |      IN     |      | RECEIVE(    )
     (    )------>|-+  +--|<------------|------|<-------(    )
     (    )       |  \/   |             |      |        (    )
     (    ) (IN)  |  /\   |  OUT+DATA   |      | (OUT)  (    )
     (    )<------|-+  +--|------------>|------|------->(    )
     (____)       |_______|             |______| +DATA  (____)

     |<---- Host K ------>|<-- Network-->|<----- Host L ----->|

               A Rendezvous at the Sender's Host






Bressler, et al.            Experimentation                     [Page 7]

RFC 333          MESSAGE SWITCHING PROTOCOL EXPERIMENT          May 1972


      ----         ______                _______          ----
     (    )       |      |              |       |        (    )
     (    ) SEND  |      |   OUT+DATA   |       | RECEIVE(    )
     (    )------>|------|------------->|-+  +--|<-------(    )
     (    )       |      |              |  \/   |        (    )
     (    ) (IN)  |      |      IN      |  /\   | (OUT)  (    )
     (    )<------|------|<-------------|-+  +--|------->(    )
     (    )       |      |              |       | +DATA  (    )
     (____)       |______|              |______ |        (____)

     |<---- Host K ----->|<-- Network-->|<----- Host L ----->|

               A Rendezvous at the Receiver's Host


  ----         ______            _______            ______         ----
 (    )       |      |          |       |          |      |       (    )
 (    ) SEND  |      | OUT+DATA |       |    IN    |      |RECEIVE(    )
 (    )------>|------|--------->|-+  +--|<---------|------|<------(    )
 (    )       |      |          |  \/   |          |      |       (    )
 (    ) (IN)  |      |    IN    |  /\   |OUT+DATA  |      | (OUT) (    )
 (    )<------|------|<---------|-+  +--|--------->|------|------>(    )
 (    )       |      |          |       |          |      | +DATA (    )
 (____)       |______|          |______ |          |______|       (____)

 |<---- Host K ----->|<--Net-->|<-Host->|<--Net-->|<----- Host L ----->|
                                   M

               A Rendezvous at an Intermediate Host

ISSUES

Timeouts.

   The issue of timeouts is a very sticky one.  A coherent system of
   timeouts simplifies everything and does away with races.  However,
   many Hosts are unwilling or unable to use timeouts, especially
   timeouts whose duration is specified.

   Without these timeouts there is probably a need for a negative
   acknowledgment which goes back to the source of an IN or OUT when one
   is timed out.  However, this now leads to races.

   A negative acknowledgment (which we will refer to as a FLUSH message)
   could be employed by a Host to mean:






Bressler, et al.            Experimentation                     [Page 8]

RFC 333          MESSAGE SWITCHING PROTOCOL EXPERIMENT          May 1972


      1. I have no room in my table

      2. I have no more available buffer space or

      3. I no longer wish to retain the table entry/buffer.

      In general, we believe that a Host should be allowed to throw away
      an IN or OUT+data whenever it is no longer convenient for the Host
      to hold the messages.  This can be immediately on the arrival of a
      message; for instance, if the Host does not want to buffer traffic
      for which it does not have a user buffer.  In lieu of timeouts,
      any time a process issues a SEND or RECEIVE, it can take it back
      by issuing the matching RECEIVE or SEND.

Blocking the Process After a Send or Receive.

      This is a question which is left implementation dependent.  In
      general, we do not think it is a good idea to block the process
      after a SEND since it may want to do another to another port or
      even do a RECEIVE.  In fact, we see nothing  inherently wrong with
      a process doing two or more SENDs to the same port as long as the
      communicating processes know what they are doing.  Of course, some
      communicating processes will prohibit several simultaneous
      messages being in transit between the same ports, for instance the
      TELNETs may well prohibit this.  However, for reasons of
      increasing bandwidth, etc., two processes may well want several
      simultaneous messages.  In this case we think it is up to the
      processes to worry about the sequencing of messages; however, we
      refer users desiring their processes to take a care of message
      sequencing to the method used in the IMP/Very Distant Host
      interface which is documented in Appendix F of BBN Report 1822.

Message Buffering

      A few points are worth mentioning with regard to message
      buffering.  First, most OUTs will probably be accompanied by data.
      Therefore, in general, since the receiver process may be swapped
      out, the receiver Host monitor must be prepared to buffer some
      data somewhere.  To minimize the amount of buffering needed, the
      monitor could refuse further traffic from the IMP until the
      earlier traffic from the IMP has been written on a disk or drum.
      Or the monitor could have a small number of buffers in the monitor
      area of memory which it fills as traffic comes from the IMP, and
      which are swapped with buffers claimed earlier by the receiver
      processes as the receiver processes are swapped in.  Note that the
      buffers may be less than the maximum subnet message size in length
      if the RECEIVEs never specify a longer message length -- of
      course, this can be enforced.  Finally note that the message size,



Bressler, et al.            Experimentation                     [Page 9]

RFC 333          MESSAGE SWITCHING PROTOCOL EXPERIMENT          May 1972


      receive-port-id, etc. are available in the first 144 bits which
      come in from the IMP.  It might be useful to read this before
      deciding into which buffer to read the rest of the message.

Positive Acknowledgments

      Built into the system is a certain form of acknowledgment.  The
      information is always available as to when the receiving process
      has done a RECEIVE.  The sending Host is assured of receiving an
      "IN" when the receive call is issued.

      Further forms of acknowledgment and validation can be implemented
      at the first user level, and advanced protocols will probably
      develop a library of such routines.

MESSAGE HEADER

      The following section deals with the specific format of Host to
      Host messages and algorithms describing the proper response to a
      given message.

      Each message begins with a 144 bit header containing the following
      fields:

      1. HOST-TO-IMP leader (32 bits) as specified in BBN Reports 1822

      2. to port ID (i.e., the id of the port receiving the message) (24
         bits)

      3. MSG TYPE (8 bits) IN, OUT, FLUSH, etc.

      4. from port ID (i.e., id or the port sending the message) (24
         bits)

      5. initiating Host's table position (8 bits) see below.

      6. HOST "sourcing" this message (8 bits) see below.

      7. RENDEZVOUS HOST (8 bits)

      8. bit count of data (16 bits)

   The header format has been arranged so that no data item will cross a
   word boundary on machines with 16, 32, and 36-bit words, except where
   the size of the item is greater than the word size.  The actual
   arrangement of bytes within words is shown in the following figures
   for these three word sizes.  For the benefit of 36-bit Hosts, bytes 4
   and 13 (numbering from 0) are unused.  The 2 and 3-byte items do not



Bressler, et al.            Experimentation                    [Page 10]

RFC 333          MESSAGE SWITCHING PROTOCOL EXPERIMENT          May 1972


   cross word boundaries except for the port ID's on the 16 bit
   machines.  This attention to packing and unpacking ease was given
   both for general convenience, and in particular because Hosts may
   wish to examine the header at interrupt level to determine where the
   rest of the message should go.

   +-------------+-------------+
0  |  HOST/IMP   | DESTINATION |
   |   FLAGS     |             |
   +-------------+-------------+
1  |   LINK      | /////////// |
   |             | /////////// |
   +-------------+-------------+
2  | /////////// |             |
   | /////////// |             |
   +-------------+             |
3  |        TO PORT ID         |
   |                           |