rfc62.txt

RFC技术文档 从0000－05

Walden                                                         [Page 5]

RFC 62                  IPC for Resource Sharing          3 August 1970


   numbers were passed on to only one copy of the executive at a time.

   It is important to distinguish between the act of passing a port from
   one process to another and the act of passing a port number from one
   process to another.  In the previous example, where characters from a
   particular teletype are sent either to the logger-process or an
   executive-process by the teletype-scanner-process, the SEND port
   always remains in the teletype-scanner-process while the RECEIVE port
   moves from the logger-process to the executive process.  On the other
   hand, the SEND port number is passed between the logger-process and
   the executive-process to enable the RECEIVE process to do a RECEIVE
   from the correct SEND port.  It is crucial that, once a process
   transfers a port to some other process, the first process no longer
   use the port.  We could add a mechanism that enforces this.  The
   protected object system of [9] is one such mechanism.  Using this
   mechanism, a process executing a SEND would need a capability for the
   SEND port and only one capability for this SEND port would exist in
   the system at any given time.  A process executing a RECEIVE would be
   required to have a capability for the RECEIVE port, and only one
   capability for this RECEIVE port would exist at a given time.
   Without such a protection mechanism, a port implicitly moves from one
   process to another by the processes merely using the port at disjoint
   times even if the port's number is never explicitly passed.

   Of course, if the protected object system is available to us, there
   is really no need for two port numbers to be specified before a
   transmission can take place.  The fact that a process knows an
   existing RECEIVE port number could be considered prima facie evidence
   of the process' right to send to that port.  The difference between
   RECEIVE and RECEIVE ANY ports then depends solely on the number of
   copies of a particular port number that have been passed out.  A
   system based on this approach would clearly be preferable to the one
   described here if it was possible to assume that all autonomous
   time-sharing systems in a network would adopt this protection
   mechanism.  If this assumption cannot be made, it seems more
   practical to require both port numbers.

   Note that in the interprocess communication system (IPC) being
   described here, when two processes wish to communicate they set up
   the connection themselves, and they are free to do it in a mutually
   convenient manner.  For instance, they can exchange port numbers or
   one process can pick all the port numbers and instruct the other
   process which to use.  However, in a particular implementation of a
   time-sharing system, the builders of the system might choose to
   restrict the processes' execution of SENDs and RECEIVEs and might
   forbid arbitrary passing around of ports and port numbers, requiring
   instead that the monitor be called (or some other special program) to
   perform these functions.



Walden                                                         [Page 6]

RFC 62                  IPC for Resource Sharing          3 August 1970


   Flow control is provided in this IPC by the simple method of never
   starting data transmission resultant from a SEND from one process
   until a RECEIVE is executed by the receiver.  Of course, interprocess
   messages may also be sent back and forth suggesting that a process
   stop sending or that space be allocated.

   Generally, well-known permanently-assigned ports are used via RECEIVE
   ANY and SEND FROM ANY.  The permanent ports will most often be used
   for starting processes and, consequently, little data will be sent
   via them.  If a process if running (perhaps asleep), and has a
   RECEIVE ANY pending, then any process knowing the receive port number
   can talk to that process without going through loggers.  This is
   obviously essential within a local time-sharing system and seems very
   useful in a more general network if the ideal of resource sharing is
   to be reached.  For instance, in a resource sharing network, the
   programs in the subroutine libraries at all sites might have RECEIVE
   ANYs always pending over permanently assigned ports with well-known
   port numbers.  Thus, to use a particular network resource such as a
   matrix manipulation hardware, a process running anywhere in the
   network can send a message to the matrix inversion subroutine
   containing the matrix to be inverted and the port numbers to be used
   for returning the results.

   An additional example demonstrates the use of the FORTRAN compiler.
   We have already explained how a user sits down at his teletype and
   gets connected to an executive.  We go on from there.  The user is
   typing in and out of the executive which is doing SENDs and RECEIVEs.
   Eventually the user types RUN FORTRAN, and executive asks the monitor
   to start up a copy of the FORTRAN compiler and passes to FORTRAN as
   start up parameters the port numbers the executive was using to talk
   to the teletype.  (This, at least conceptually, FORTRAN is passed a
   port at which to RECEIVE characters from the teletype and a port from
   which to SEND characters to the teletype.)  FORTRAN is, of course,
   expecting these parameters and does SENDs and RECEIVEs via the
   indicated ports to discover from the user what input and output files
   the user wants to use.  FORTRAN types INPUT FILE? to the user, who
   responds F001.  FORTRAN then sends a message to the file-system-
   process, which is asleep waiting for something to do.  The message is
   sent via well-known ports and it asks the file system to open F001
   for input. The message also contains a pair of port numbers that the
   file-system process can use to send its reply.  The file-system looks
   up F001, opens it for input, make some entries in its open file
   tables, and sends back to FORTRAN a message containing the port
   numbers that FORTRAN can use to read the file.  The same procedure is
   followed for the output file.  When the compilation is complete,
   FORTRAN returns the teletype port numbers (and the ports) back to the
   executive that has been asleep waiting for a message from FORTRAN,
   and then FORTRAN halts itself.  The file-system-process goes back to



Walden                                                         [Page 7]

RFC 62                  IPC for Resource Sharing          3 August 1970


   sleep when it has nothing else to do<4>.

   Again, the file-system process can keep a small collection of port
   numbers which it uses over and over if it can get file system users
   to return the port numbers when they have finished with them.  Of
   course, when this collection of port numbers has eventually dribbled
   away, the file system can get some new unique numbers from the
   monitor.


3. A System for Interprocess Communication Between Remote Processes

   The IPC described in the previous section easily generalizes to allow
   interprocess communication between processes at geographically
   different locations as, for example, within a computer network.

   Consider first a simple configuration of processes distributed around
   the points of a star.  At each point of the star there is an
   autonomous operating system<5>.  A rather large, smart computer
   system, called the Network Controller, exists at the center of the
   star.  No processes can run in this center system, but rather it
   should be thought of as an extension of the monitor of each of the
   operating systems in the network.

   If the Network Controller is able to perform the operations SEND,
   RECEIVE, SEND FROM ANY, RECEIVE ANY, and UNIQUE and if all of the
   monitors in all of the time-sharing systems in the network do not
   perform these operations themselves but rather ask the Network
   Controller to perform these operations for them, then the problem of
   interprocess communication between remote processes if solved.  No
   further changes are necessary since the Network Controller can keep
   track of which RECEIVEs have been executed and which SENDs have been
   executed and match them up just as the monitor did in the model
   time-sharing system.  A networkwide port numbering scheme is also
   possible with the Network Controller knowing where (i.e., at which
   site) a particular port is at a particular time.

   Next, consider a more complex network in which there is no common
   center point, making it necessary to distribute the functions
   performed by the Network Controller among the network nodes.  In the
   rest of this section I will show that it is possible to efficiently
   and conveniently distribute the functions performed by the star
   Network Controller among the many network sites and still enable
   general interprocess communication between remote processes.

   Some changes must be made to each of the four SEND/RECEIVE operations
   described above to adapt them for use in a distributed Network
   Controller.  To RECEIVE is added a parameter specifying a site to



Walden                                                         [Page 8]

RFC 62                  IPC for Resource Sharing          3 August 1970


   which the RECEIVE is to be sent.  To the SEND FROM ANY and SEND
   messages is added a site to send the SEND to although this is
   normally the local site.  Both RECEIVE and RECEIVE ANY have added the
   provision for obtaining the source site of any received message.
   Thus, when a RECEIVE is executed, the RECEIVE is sent to the site
   specified, possibly a remote site.  Concurrently a SEND is sent to
   the same site, normally the local site of the process executing the
   SEND.  At this site, called the rendezvous site, the RECEIVE is
   matched with the proper SEND and the message transmission is allowed
   to take place from the SEND site to the site from whence the RECEIVE
   came.

   A RECEIVE ANY never leaves its originating site and therein lies the
   necessity for SEND FROM ANY, since it must be possible to send a
   message to a RECEIVE ANY port and not have the message blocked
   waiting for a RECEIVE at the sending site.  It is possible to
   construct a system so the SEND/RECEIVE rendezvous takes place at the
   RECEIVE site and eliminates the SEND FROM ANY operation, but in my
   judgment the ability to block a normal SEND transmission at the
   source site more than makes up for the added complexity.

   At each site a rendezvous table is kept.  This table contains an
   entry for each unmatched SEND or RECEIVE received at that site and
   also an entry for all RECEIVE ANYs given at that site.  A matching
   SEND/RECEIVE pair is cleared from the table as soon as the match
   takes place.  As in the similar table kept in the model time-sharing,
   SEND and RECEIVE entries are timed out if unmatched for too long and
   the originator is notified.  RECEIVE ANY entries are cleared from the
   table when a fulfilling message arrives.

   The final change necessary to distribute the Network Controller
   functions is to give each site a portion of the unique numbers to
   distribute via its UNIQUE operation.  I'll discuss this topic further
   below.

   To make it clear to the reader how the distributed Network Controller
   works, an example follows.  The details of what process picks port
   numbers, etc., are only exemplary and are not a standard specified as
   part of the IPC.

   Suppose that, for two sites in the network, K and L, process A at
   site K wishes to communicate with process B at site L.  Process B has
   a RECEIVE ANY pending at port M.








Walden                                                         [Page 9]

RFC 62                  IPC for Resource Sharing          3 August 1970


                        SITE K                        SITE L

                        ______                        ______
                       /      \                      /      \
                      /        \                    /        \
                     /          \                  /          \
                    /            \                /            \
                   |              |              |              |
                   |   Process A  |              |   Process B  |
                   |              |              |              |
                    \            /                \            /
                     \          /      RECEIVE--> port M      /
                      \        /       ANY          \        /
                       \______/                      \______/


   Process A, fortunately, knows of the existence of port M at site L and
   sends a message using the SEND FROM ANY operation from port N to port
   M.  The message contains two port numbers and instructions for process
   B to SEND messages for process A to port P from port Q.  Site K's site
   number is appended to this message along with the message's SEND port N.

                        SITE K                        SITE L

                        ______                        ______
                       /      \                      /      \
                      /        \                    /        \
                     /          \                  /          \
                    /            \                /            \
                   |              |              |              |
                   |   Process A  |              |   Process B  |
                   |              |              |              |
                    \   port N   /                \   port M   /
                     \          /--->SEND FROM --->\          /
                      \        /        ANY         \        /
                       \______/                      \______/

                                   to port M, site L

                                   containing K,N,P, & Q

   Process A now executes a RECEIVE at port P from port Q.  Process A
   specifies the rendezvous site to be site L.








Walden                                                        [Page 10]