rfc333.txt

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

   process wanted a unique number which it could depend on not to be
   used for all time or until the number is given back, it would send a
   RECEIVE-from-SPECIFIC specifying the well-known port of the Unique
   Number Process and rendezvous at the Unique Number Process' Host.
   The Unique Number Process' pending SEND-to-ANY would contain a unique
   number.  Also, the Unique Number Process would have a RECEIVE-from-



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


   ANY always pending at another well-known port with local rendezvous
   specified.  At this port the Unique Number Process would receive
   unique numbers which processes are giving back.  The Unique Number
   Process would maintain a bit table 2-16- bits long indicating the
   state of each of its unique numbers (free or in use) in some long-
   term storage medium such as in the file system.  The Unique Number
   Process might also maintain some information about each process to
   which it gives a unique number so that when the supply of unique
   number gets depleted, processes can be asked to return them.

   It has already been mentioned that some of the process ID's
   registered along with their symbolic names at the information
   operator might be long-term unique numbers gotten from the Unique
   Number Process.  It should also be mentioned that there would seem to
   be no reason, other than scarcity of storage space, that in addition
   to the port number through which primary access is gained to a
   process and which was called the process ID in the previous section,
   arbitrary port numbers along with their symbolic identified could not
   be registered with an information operator.  For instance, rather
   than registering the name BBN-FORTRAN and a single port number, one
   could perhaps register the port numbers whose symbolic identifiers
   were BBN-FORTRAN-CONTROL-TELETYPE, BBN-FORTRAN-INPUT-FILE, BBN-
   FORTRAN-LISTING-FILE, and BBN-FORTRAN-BINARY-OUTPUT-FILE.  This is
   perhaps at odds with standard practice within operating systems, but
   is consistent with the philosophy of reference 4 that communication
   is done with ports and not processes.

   Let us now address an issue which has been ignored up to now and
   which was only alluded to in reference 4, the issue of port
   protection.  We have not given this matter a great deal of thought;
   however, one mechanism for port protection seems quite
   straightforward.  The heart of this mechanism is a process at each
   Host which we shall call (alliteratively) the Port Protection Process
   (PPP).  The PPP maintains a list of all processes which exist at the
   Host and for each process the numbers of all ports which the process
   has "legally" obtained.  Every time a process does a SEND or RECEIVE,
   the monitor checks with the PPP to see if the process has specified
   port numbers it has the right to use; i.e., those legally obtained.
   The PPP has some RECEIVEs always pending at well-known ports.  When
   one process wants to pass a port to some other process, the first
   process sends a message to the PPP specifying the number of the port
   to be sent, the Host number at which the second process resides, a
   port at which the second process is expecting to receive the port,
   etc.  The PPP looks up in its tables whether the first process has
   the port it wants to send.  If it does, it sends a message to the PPP
   at the destination site.  The message contains the number of the port
   to be transferred and the RECEIVE port for the destination process.
   The destination PPP checks in its table whether the process has the



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


   RECEIVE port, and if so, passes the new port to the process and
   updates its tables to indicate the process now possesses the new
   port.  The messages to a PPP will optionally be able to specify that
   a copy of a port be sent, a port be deleted, etc.  The PPPs would
   probably have some built-in legal ports for each process,
   particularly the port's processes used to communicate with the PPP.
   The exact specification requires development but that should not be
   hard (see (3),(6), and (7) in reference 4).  The main difficulty we
   see is efficient checking of the PPP's tables by the monitor for
   every RECEIVE or SEND without entirely supplanting the monitor's
   current protection system.

FLOW CHART

   The following section describes a flow chart for most of the MSP.  A
   distinction is made between calls made by local processes called SEND
   and RECEIVE, and messages coming in over the NET called IN and OUT.
   An additional distinction is made between calls (or messages) with a
   local rendezvous and those with a foreign rendezvous Host.

   Since the code is quite similar, the distinction need not be made,
   but will be included for the sake of clarity.

   It is assumed that the MSP has table provisions for the following
   items:

      source of message
      rendezvous Host
      FROM-PORT-ID
      TO-PORT-ID
      table position
      type of message
      data size and location
      data about the user process

   User does a SEND or RECEIVE

   A. Rendezvous is at a foreign host

      1. Store the appropriate table data

      2. Send a message to the rendezvous host

         a. SEND: OUT + DATA

         b. RECEIVE: IN

   B. Rendezvous is local - look for entry in table



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


      1. Entry NOT found: create entry with appropriate data

      2. A matching entry exists in table:

         a. RECEIVE: give user the data

         b. Send a message to the other host (as specified by the source
            field of the original msg)

            1)SEND: OUT+DATA
            2)RECEIVE: IN

         c. Alert user to the fact that transaction is complete

         d. Clear table entry

   An IN is received over the NET-search table for matching entry.

   A. No matching entry create an entry with appropriate data.

   B. A match exists

      1. Entry was cause by a local SEND

         a. Send "OUT _ DATA" to source of IN

         b. Inform user of transaction

         c. Clear table entry

      2. Entry was caused by an OUT received over net-acting as third
         host.

         a. Send IN to site that created table entry

         b. Send OUT + DATA (previously buffered) to site sending the IN

         c. Clear table entry

   An OUT + DATA is received over the NET -search table for matching
   entry

   A. No match is found

      1. buffer data

      2. create appropriate table information




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


   B. A match is found

      1. Table entry was caused by locally executed RECEIVE

         a. give data to the user and alert him to its existence.

         b. send a matching "IN" to the source of the "OUT"

         c. remove entry from table

      2. Table entry was caused by the receipt of an "IN" over the NET,
         thus we are acting as a third party host

         a. send the "OUT + DATA" to the host stored in the table

         b. send an "IN" to the host from which the "OUT" had just
         arrived.

MSP VARIATIONS

   It may of interest to the reader to know of some of the other MSPs we
   have considered while arriving at the present one.

   The simplest we considered is an MSP based on all rendezvous being
   done at the destination Host.  The sender process sends an OUT-
   message plus the data to the destination Host.  The receiver process
   does an IN which stays at the receivers Host.  The OUT and RECEIVE
   rendezvous and the data is passed to the receiver process.  The
   transmission is now complete, except in some variations of this MSP
   an acknowledgement is sent to the sender process.  This MSP has
   couple of disadvantages: In the simplest formulation, the RECEIVE had
   to be waiting when the OUT+data arrived, otherwise the out data were
   thrown away.  This puts too tight a constraint on the timing of the
   SEND and RECEIVE, especially since the sender and receiver processes
   can be a continent apart.  However, if the IN is allowed to arrive
   first and must be held until matched by a RECEIVE, the monitor must
   buffer an indeterminate amount of data in all cases including the
   normal one.  Further, basing everything on rendezvous at the
   destination makes the process of moving a port difficult.

   The next simplest MSP we considered was the IPC of reference 4.  This
   works just the opposite of the above described MSP in that it is
   based on almost all rendezvous being done at the source Host with two
   special messages to handle the relatively uncommon cases when a
   rendezvous must be done at the destination or an intermediate Host.
   This system, its advantages, and disadvantages is discussed at very
   great length in the reference.




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


   A third variation on the MSP, suggested by Crowther, is the same as
   the present MSP in that the OUT and IN rendezvous at a process
   specified rendezvous Host and the OUT is sent to the source of the IN
   and the IN to the source of the OUT, but the data is not sent along
   with the OUT.  Instead, when the OUT finally reaches the source of
   the IN, another message is sent from the receiver Host to the source
   Host requesting the data to be sent.  The data finally is transmitted
   to the destination in response to this data request message.  Our
   main objection to this system is its lack of symmetry, but we do
   recognize that it does not require any Host to buffer data for which
   a process has not set up an input buffer and perhaps for that reason
   it is a better system than the MSP we are presenting.

   In the last MSP variation we considered, the difference between SEND
   or RECEIVE and OUT or IN was discarded.  In this case only one
   message is used which we will call TRANSFER.  When a process executes
   a TRANSFER it can specify an input buffer, an output buffer, both, or
   neither.  Two processes wishing to communicate both execute TRANSFERs
   specifying the same to and from port ids and the same rendezvous
   Host.  The TRANSFERs result in TRANSFER-messages plus data in the
   case that an output buffer was specified which rendezvous at the
   rendezvous Host.  When the rendezvous occurs, the TRANSFER-messages
   plus their data cross and each is sent to the source of the other.
   The system allows processes not to know whether they must do a SEND,
   or RECEIVE and is (perhaps) a nice generalization of the MSP
   presented in this note.  For instance, two processes can exchange
   data using this system, or two processes can kind of interrupt each
   other by sending dataless TRANSFERs.  This variation of the MSP is a
   development of a suggestion of Steve Crocker.  Its disadvantages are:
   (1) unintentional matches are more likely to occur, (2) rendezvous
   selection site is more complex, and (3) it's hard to think about.

APPENDIX

   A system for Interprocess Communication in a Resource Sharing
   Computer Network.  Communications of the ACM, April, 1972.
   Permission to reprint this paper was granted by permission of the
   Association for Computing Machinery. [Omitted in republished version
   of RFC 333.]

   N.B. The ideas of section 4 of the following paper are in no way
   critical to the ideas developed in section 3--DCW.


         [ This RFC was put into machine readable form for entry ]
            [ into the online RFC archives by Via Genie 3/00  ]





Bressler, et al.            Experimentation                    [Page 26]