rfc61.txt

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

Network Working Group                                        Dave Walden
Request for Comments: 61                         Bolt Beranek and Newman
                                                           July 17, 1970

                  A Note on Interprocess Communication
                in a Resource Sharing Computer Network


   The attached note is a draft of a study I am still working on.  It
   may be of general interest to network participants.









































Walden                                                          [Page 1]

RFC 61      Interprocess Communication in a Computer Network   July 1970


                        Interprocess Communication
                                   in a
                     Resource Sharing Computer Network

INTRODUCTION

   "A resource sharing computer network is defined to be a set of
   autonomous, independent computer systems, interconnected so as to
   permit each computer system to utilize all of the resources of each
   other computer system.  That is, a program running in one computer
   system should be able to call on the resources of the other computer
   systems much as it would normally call a subroutine."  This
   definition of a network and the desirability of such a network is
   expounded upon by Roberts and Wessler in [1].

   The actual act of resource sharing can be performed in two ways: in a
   pairwise ad hoc manner between all pairs of computer systems in the
   network or according to a systematic network wide standard.  This
   paper develops one possible network wide system for resource sharing.

   I believe it is natural to think of resources as being associated
   with processes [2] and therefore view the fundamental problem of
   resource sharing to be the problem of interprocess communication.  I
   also share with Carr, Crocker, and Cerf [3] the view that
   interprocess communication over a network is a subcase of general
   interprocess communication in a multiprogrammed environment.

   These views pervade this study and have led to a two part study.
   First, a model for a time-sharing system having capabilities
   particularly suitable for enabling interprocess communication is
   constructed.  Next, it is shown that these capabilities can be easily
   used in a generalized manner which permits interprocess communication
   between processes distributed over a computer network.

   This note contains ideas based on many sources.  Particularly
   influential were -- 1) an early sketch of a Host protocol for the
   ARPA Network [1][3][4] by W. Crowther of Bolt Beranek and Newman Inc.
   (BBN) and S. Crocker of UCLA; 2) Ackerman and Plummer's paper on the
   MIT PDP-1 time sharing system [5]; and 3) discussion with R. Kahn of
   BBN about Host protocol, message control, and routing for the ARPA
   Network.  Hopefully, there are also some original ideas in this note.
   I alone am responsible for the collection of all of these ideas into
   the system described herein, and I am therefore responsible for any
   inconsistencies or bugs in this system.

   It must be emphasized that this note does not represent an official
   BBN position on Host protocol for the ARPA Computer Network.




Walden                                                          [Page 2]

RFC 61      Interprocess Communication in a Computer Network   July 1970


A MODEL FOR A TIME-SHARING SYSTEM

   This section describes a model time-sharing system which I think is
   particularly suitable for performing interprocess communication.  The
   basic structure of this model time-sharing system is not original
   [5][9].

   The model time-sharing system has two pieces: the monitor and the
   processes.  The monitor performs several functions, including
   switching control from process to process as appropriate (e.g., when
   a process has used "enough" time or when an interrupt occurs),
   managing core and the swapping medium, controlling the passing of
   control from one process to another (i.e., protection mechanisms),
   creating processes, caring for sleeping processes, etc.

   The processes perform most of the functions normally thought of as
   being supervisor functions in a time-sharing system (system
   processes) as well as the normal user functions (user processes).  A
   typical system process is the disc handler or the file system.  For
   efficiency reasons it may be useful to think of system processes as
   being locked in core.

   A process can call on the monitor to perform several functions: start
   another, equal, autonomous process (i.e., load a program or find a
   copy of a program somewhere that can be shared, start it, and pass it
   some initial parameters); halt the running process; put the current
   process to sleep pending a specified event; send a message to a
   specified process; become available to receive a message from a
   specified process; become available to receive a message from any
   process; send a message to a process able to receive from any
   process; and request a unique number.  There undoubtedly should also
   be other monitor functions.  It is left as an exercise to the reader
   to convince himself that the monitor he is saddled with can be made
   to provide these functions -- most can.

   I will not concern myself with protection considerations here, but
   instead will assume all of the processes are "good" processes which
   never make any mistakes.  If the reader needs a protection structure
   to keep in mind while he reads this note, the _capability_ system
   described in [5][6][7][8] should be satisfying.

   We now look a little closer at the eight operations listed above that
   a process can ask the monitor to perform.








Walden                                                          [Page 3]

RFC 61      Interprocess Communication in a Computer Network   July 1970


   START.  This operation starts another process.   It has two
   parameters -- some kind of identification for the program that is to
   be loaded and a parameter list for that program.   Once the program
   is loaded, it is started at its given entry point and passed its
   parameter list in some well known manner.  The process will continue
   to exist until it halts itself.

   HALT.  This operation puts the currently running process to sleep
   pending the completion of some event.  The operation has one
   parameter, the event to be waited for.  Sample events are arrival of
   a hardware interrupt, arrival of a message from another process, etc.
   The process is restarted at the instruction after the SLEEP command.
   The monitor never unilaterally puts a process to sleep except when
   the process overflows its quantum.

   RECEIVE.  This operation allows another process to send a message to
   this process.  The operation has four parameters: the port (defined
   below) awaiting the message, the port a message will be accepted
   from, a specification of the buffer available to receive the message,
   and a location of transfer to when the transmission is complete.  [In
   other words, an interrupt location.  Any message port may be used to
   allow interrupts, event channels, etc.  The user programs what he
   wants.]

   SEND.  This operation sends a message to some other process.  [I
   suppose a process could also send a message to itself.]  It has four
   parameters: a port to send the message to, the port the message is
   being sent from, the message, and a location to transfer to when the
   transmission is complete.

   RECEIVE ANY.  This operation allows any process to send a message to
   this process.  The operation has four parameters: the port awaiting
   the message, the buffer available to receive the message, a location
   to transfer to when the message is received, and a location where the
   port which sent the message may be noted.

   SEND FROM ANY.  This operation allows a process to send a message to
   a process able to receive a message from any process.  It has the
   same four parameters as SEND.  The necessity for this operation will
   be discussed below.

   UNIQUE.  This operation obtains a unique number from the monitor.

   A _port_ is a particular data path to or from a process.  All ports
   have an associated unique number which is used to identify the port.
   Ports are used in transmitting messages from one process to another
   in the following fashion.  Consider two processes, A and B, wishing
   to communicate.  Process A executes a RECEIVE at port N from port M.



Walden                                                          [Page 4]

RFC 61      Interprocess Communication in a Computer Network   July 1970


   Process B executes a SEND to port N from port M.  The monitor matches
   up the port numbers and transfers the message from process B to
   process A.  As soon as the buffer has been fully transmitted out of
   process B, process B is restarted at the location specified in the
   SEND operation.  As soon as the message is fully received at process
   A, process A is restarted at the location specified in the RECEIVE
   operation.  Just how the processes come by the correct port numbers
   with which to communicate with other processes is not the concern of
   the monitor -- this problem is left to the processes.

   An example.  Suppose that our model time-sharing system is
   initialized to have several processes always running.  Additionally,
   these permanent processes have some universally known and permanently
   assigned ports.  [Or perhaps there is only one permanently known port
   which belongs to a directory-process which keeps a table of
   permanent-process/well-known-port associations.]  Suppose that two of
   the permanently running processes are the logger-process and the
   teletype-scanner-process.  When the teletype-scanner-process first
   starts running, it puts itself to sleep awaiting an interrupt from
   the hardware teletype scanner.  The logger-process initially puts
   itself to sleep awaiting a message from the teletype-scanner-process
   via well-known permanent SEND and RECEIVE ports.  The teletype-
   scanner-process keeps a table indexed by teletype number containing
   in each entry a port to send characters from that teletype to, and a
   port at which to receive characters for that teletype.  If a
   character arrives (waking up the teletype-scanner-process) and the
   process does not have any entry for that teletype, it gets a pair of
   unique numbers from the monitor (via UNIQUE) and sends a message
   containing this pair of numbers to the logger-process using the ports
   that the logger-process is known to have a RECEIVE pending for.
   [Actually, the scanner process could always use the same pair of port
   numbers for a particular teletype as long as they were passed on to
   only one copy of the executive at a time.]  The scanner-process also
   enters the pair of numbers in the teletype table, and sends the
   characters and all future characters from this teletype to the port
   with the first number from the port with the second number.  The
   scanner-process probably also passes a second pair of unique numbers
   to the logger-process for it to use for teletype output and does a
   RECEIVE using these numbers.  The logger-process when it receives the
   message from the scanner-process, starts up a copy of what SDS 940
   TSS [12] users call the executive (that program which prints file
   directories, tells who is on other teletypes, runs subsystems, etc.)
   and passes this copy of the executive, the port numbers so this
   executive-process can also do its in's and out's to the teletype
   using these ports.  If the logger-process wants to get a job number
   and password from the user, it can temporarily use the port numbers
   to communicate with the user before it passes them on to the
   executive.



Walden                                                          [Page 5]

RFC 61      Interprocess Communication in a Computer Network   July 1970


   _Port numbers_ are often passed among processes.  More rarely, a port
   is transferred to another process.  It is crucial that once a process
   transfers a _port_ to some other process that the first process no
   longer use the port.  We could add a mechanism that enforces this.
   The protected object system of [8] is one such mechanism.  [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 is 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 all of the autonomous time-sharing
   system 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 somewhere in the monitor there must be a table of  port
   numbers associated with processes and restart locations.  The table
   entries are cleared after each SEND/RECEIVE match is made.  Also note
   that if a process is running (perhaps asleep), and has RECEIVE ANY
   pending, then any process knowing the receive port number can talk to
   that process without going through loggers or any of that.  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.

   When a SEND is executed, nothing happens until a matching RECEIVE is
   executed.  If a proper RECEIVE is not executed for some time the SEND
   is timed out after a while and the SENDing process is notified.  If a
   RECEIVE is executed but the matching SEND does not happen for a long
   time, the RECEIVE is timed out and the RECEIVing process is notified.

   A RECEIVE ANY never times out, but may be taken back.  A SEND FROM
   ANY message is always sent immediately and will be discarded if a
   proper receiver does not exist.  An error message is not returned and
   acknowledgment, if any, is up to the processes.  If the table where
   the SEND and RECEIVE are matched up ever overflows, a process
   originating a further SEND or RECEIVE is notified just as if the SEND
   or RECEIVE timed out.

   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 going and consequently little data
   will be sent via them.





Walden                                                          [Page 6]