rfc333.txt

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

   +-------------+-------------+
4  |  MESSAGE    |             |
   |   TYPE      |             |
   +-------------+             |
5  |        FROM PORT ID       |
   |                           |
   +-------------+-------------+
6  |  TABLE      | /////////// |
   |  POSITION   | /////////// |
   +-------------+-------------+
7  |  SOURCE     | RENDEZVOUS  |
   |   HOST      |   HOST      |
   +-------------+-------------+
8  |        BIT COUNT          |
   |                           |
   +-------------+-------------+
   |                           |
9  |           DATA            |
   //                         //
   |                           |
   +-------------+-------------+

         16-bit Host Format

   +-------------+
   |             |            ////////// = unused
   |             |            //////////
   +-------------+
       8 bits




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


   0             8            16            24            32     36
   +-------------+-------------+-------------+-------------+------+
0  | HOST/IMP    |   FOREIGN   |    LINK     | ////////////////// |
   |  FLAGS      |   HOST      |             | ////////////////// |
   +------+------+-------------+-------------+-------+-----+------+
1  | //// |        TO PORT ID                        |  MESSAGE   |
   | //// |                                          |   TYPE     |
   +------+------+-------------+-------------+-------------+------+
2  |               FROM PORT ID              |   TABLE     | //// |
   |                                         |   POSITION  | //// |
   +------+-------------+-------------+------+-------------+------+
3  | //// |   SOURCE    | RENDEZVOUS  |          BIT COUNT        |
   | //// |    HOST     |  HOST       |                           |
   +------+-------------+-------------+---------------------------+
   |                                                              |
4  |                                                              |
   //                          DATA                              //
   |                                                              |
   |                                                              |
   +-------------+-------------+-------------+-------------+------+

                         36-bit Host Format


   +-------------+-------------+-------------+-------------+
0  | HOST/IMP    |   FOREIGN   |    LINK     | /////////// |
   |  FLAGS      |   HOST      |             | /////////// |
   +-------------+-------------+-------------+-------------+
1  | /////////// |             TO PORT ID                  |
   |             |                                         |
   +-------------+-------------+-------------+-------------+
2  |  MESSAGE    |             FROM PORT ID                |
   |   TYPE      |                                         |
   +-------------+-------------+-------------+-------------+
3  |  TABLE      | /////////// |  SOURCE     | RENDEZVOUS  |
   |  POSITION   | /////////// |   HOST      |   HOST      |
   +-------------+-------------+-------------+-------------+
   |        BIT COUNT          |                           |
   |                           |                           |
   +-------------+-------------+                           |
   |                                                       |
   //                   DATA                              //
   |                                                       |
   +-------------+-------------+-------------+-------------+

                         32-bit Host Format





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


   The fields within the Host/IMP leader are already familiar to NCP
   programmers however, two points about these fields are worth
   mentioning.  First, the destination field originally contains the
   number of the rendezvous Host.  After rendezvous at a intermediate
   site, the destination field contains the source of the message
   rendezvous with.  Second, the link field for the MSP experiment can
   only contain link number 192-195.  We have not taken the time to
   figure out a sensible allocation of these four links among all the
   messages which might be sent using the MSP.  One alternative is to
   cycle over the links to increase the bandwidth of the "pipe" between
   any two Hosts. For the time being, until further consideration is
   given to this issue, we suggest each Host at a site using one
   (unique) link for all its communication.

   The message types we have to represent in the message type field are
   few now: we suggest message type 2 for SEND or OUT messages and
   message 3 for RECEIVE or IN messages.  Message type 4 is the FLUSH
   message, if FLUSH is used.

   The rendezvous Host field needs no comment.  Except that the field is
   unnecessary after the rendezvous has taken place and could then be
   used for something else.

   The bit count is a count of data bits in an OUT message or the size
   of the input buffer (not including the header) in an IN message.
   Thus the sender process can tell from the IN message bit count when
   it receives the IN message how much of the data in the OUT message
   was accepted by the receiver process and can use this knowledge to
   retransmit the remainder of the message if so desired.  After the
   rendezvous, we recommend that all of the data in the message be sent
   on the source of the IN message even if the OUT bit count was greater
   than the IN bit count.  Thus, at the receiver Host the monitor has
   the option (if it wants to take it) of discarding the message for
   being too long, sending the number of bits the receiver process has
   done an IN for into the receiver process and discarding the rest, or
   queuing the rest of the bits and somehow notify the receiver process
   that there are more bits which the receiver process can ask for.

   The to- and from-port-id fields are 24-bit numbers.  This size was
   chosen to help the TIPs.  The first eight bits of a port Id should be
   the number of the Host at which this port id was created.  Note well,
   that this is not necessarily the Host at which the port is being
   used.  This is necessary since rendezvous take place at intermediate
   sites and because ports may move from site to site.  We suggest that
   all port ids with the first eight bits all zero be reserved for
   network-wide use.  In particular, a port id with all 24 bits zero
   will be used to mean "ANY".  This gives us the options of:




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


            RECEIVE from ANY to SPECIFIC

            RECEIVE from SPECIFIC to SPECIFIC

            SEND from SPECIFIC to ANY

       and  SEND from SPECIFIC to SPECIFIC

   Examples of the use of these options will be given below.

   The other options (RECEIVE to ANY) and (SEND from ANY) we feel are
   kind of useless but would not prohibit them.  We believe that in the
   absence of explicit specification of rendezvous Host, the use of an
   ANY port id in the user's system call should affect the default
   rendezvous site as follows:

      RECEIVE from ANY--rendezvous in receiver

      RECEIVE from SPECIFIC--rendezvous in sender

      SEND to ANY--rendezvous in sender

      SEND to SPECIFIC--rendezvous in sender

   The less significant 16 bits of the id can be used however a Host
   wants to.  For instance, eight bits might be used as a process id and
   eight bits might be used as a channel specification within the
   specified process.  We suggest that each Host reserve the port ids
   with the middle eight bits all zero for special uses as well known
   ports.

   The table position field is included to help prevent costly table
   searches at interrupt level.  Hosts sending INs and OUTs, put in the
   table position field the rendezvous table position of the SEND or
   RECEIVE associated with the IN or OUT.  At an intermediate Host
   rendezvous, the table position fields in the matching IN and OUT are
   swapped so that when the messages arrive at the opposite end, the
   matching SEND and RECEIVE can be found quickly.  The MSP must do the
   swap at the rendezvous, but of course the MSPs need not fill in the
   table position field when first transmitting an IN or OUT in which
   case the information arriving in an IN or OUT will be meaningless.
   The general algorithm, then, is to check the table position as
   specified in this field and if that fails, search the whole table.

   The source field is filled in INs and OUTs by the MSP which
   originally sends these messages.  At the rendezvous the source of
   each message is preserved in the message being forwarded to the final
   Host.  When an IN or OUT arrives at a process, the process can use



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


   the source information to update its understanding of the rendezvous
   Host (e.g., when the destination Host and rendezvous Host are
   different).


EXAMPLES

The typical example.

   We envision communication normally taking place using specifications
   to and from ports and rendezvous at the sender.  For instance, the
   TIP would probably send to other Hosts using this method and would
   certainly receive from other Host until the TIP asks for it.  In this
   "normal" method a monitor could even look at the bit count in the
   arriving IN-message, use that as an allocation and then simulate an
   OUT-message of the exact correct length.

The logging example

   Consider an example of SEND to SPECIFIC and RECEIVE from ANY with the
   rendezvous at the receiver.  This method might be used by some
   logging receiver process with a well-known to-port.  For instance, a
   measurements program to which statistics are sent from many processes
   throughout the net.

The program library example

   Suppose within a given time-sharing system there is a particular
   library routine which is available for use by any process in the
   network.  The library process has a RECEIVE from ANY always pending
   at a well-known port.  Eventually, some process sends a message to
   the library process' well-known-port.  This message includes the data
   to be processed, a port to use for sending the answer, and the money.
   The library process takes some of the money and sends it to the
   well-known port of the accounting process which itself has a RECEIVE
   from ANY pending.  The library process then processes the data and
   sends the answer back to the process which requested the service
   using a SEND to SPECIFIC message which rendezvous at the destination
   where there is already a RECEIVE from SPECIFIC pending.  Of course,
   in this message besides the answer, any change the requesting process
   has coming is returned.

A comment

   As can be seen from our examples, we think rendezvousing at an
   intermediate Host will seldom be done as the chief benefit of this
   comes when it is desirable to move a port (see reference 4 for a
   discussion of this).  We would like to see all Hosts provide some



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


   (meager) amount of buffering for this purpose but would not require
   it.  It shouldn't be too painful to provide a little of this kind of
   buffering-especially since a Host can throw away any message it can't
   handle.

   (THIS PAGE WILL BE REPLACED WITH A BETTER DESCRIPTION OF TELNET UNDER
   MSP IN A FEW DAYS--DCW)

TELNET

   Let us postulate a pair of Telnet programs that maintain two
   bidirectional communication paths, one for data and one for control.
   Let us also assume, for convenience that the port IDs are as follows:

      If the WRITE-CONTROL-ID is N, then --

         READ-CONTROL-ID=N+1,

         WRITE-DATA=N+2,

         READ-DATA=N+3.

   The initial state is the server Telnet sitting with a READ-FROM-ANY
   pending.

   The user Telnet now issues a SEND-TO-SPECIFIC with the data field
   containing the PORT-ID of the SERVER's WRITE-CONTROL-ID. This message
   is sent from the user-Telnet's WRITE-CONTROL-ID.

   Thus all port IDs are specified by the user Telnet, so, if desired,