rfc61.txt

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


RFC 61      Interprocess Communication in a Computer Network   July 1970


   Still another example, this time a demonstration of 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 the
   executive asks the monitor to start up a copy of the FORTRAN compiler
   and passes to FORTRAN as start up parameters the two ports the
   executive was using to talk to the teletype.  FORTRAN is of course
   expecting these parameters and does SENDs and RECEIVEs to these ports
   to discover 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 ports that the file-system-process
   can use to send its reply.  The file-system looks up F001, opens it
   for input, makes some entries in its open file tables, and sends a
   message back to FORTRAN which contains the ports which 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 back to the executive which has been asleep waiting for
   a message from FORTRAN, and then FORTRAN halts itself.  The file-
   system-process goes back to sleep when it has nothing else to do.

   [The reader should have noticed by now that I do not like to think of
   a new process (consisting of a new conceptual copy of a program)
   being started up each time another user wishes to use the program.
   Rather, I like to think of the program as a single process which
   knows it is being used simultaneously by many other processes and
   consciously multiplexes among the users or delays service to users
   until it can get around to them.]

   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 are done 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.

   Note that 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.  Of course, 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 port numbers, requiring instead
   that the monitor be called (or some other special program) to perform
   these functions.



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


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

INTERPROCESS COMMUNICATION BETWEEN REMOTE PROCESS

   The system 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 time-sharing system.  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 time-
   sharing system in the network.

   It should be obvious to the reader that if the Network Controller is
   able to perform the operations SEND, RECEIVE, SEND FROM ANY, RECEIVE
   ANY, and UNIQUE and that 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 we have solved the problem of interprocess
   communication between remote processes.  We have no further change to
   make.

   The reason everything continues to work when we postulate the
   existence of the Network Controller is that 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.  To
   RECEIVE is added a parameter specifying a site to which the RECEIVE



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


   is to be sent.  To SEND FROM ANY and SEND 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 obtain 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 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.  It must be possible to send a message
   to a RECEIVE ANY port and not have the message blocked waiting for
   RECEIVE at the sending site.  Of course, it would be possible to
   construct the system so the SEND/RECEIVE rendezvous takes place at
   the RECEIVE site and eliminate 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.

   Somewhere 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 or perhaps when the transmission is complete.  As
   in the similar table kept in the model time-sharing system, 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 system.

   Suppose there are 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 61      Interprocess Communication in a Computer Network   July 1970


                    SITE K              SITE L
                  ________            ________
                 /        \          /        \
                /          \        /          \
               /            \      /            \
              |  Process A   |    |   Process B  |
              |              |    |              |
              |              |    |              |
               \            /      \            /
                \          /        \   port M /
                 \________/          \____^___/
                                          |
                                      RECEIVE ANY

   Process A, fortunately, knows of the existence of port M at site L
   and sends messages 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 to 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  /--->SEND FROM --->\  port M  /
                \________/       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]

RFC 61      Interprocess Communication in a Computer Network   July 1970


                    SITE K                         SITE L
                  ________                 R    ________
                 /        \                e   /        \
                /          \               n T/          \
               /            \              d a            \
              |              |             e b  Process B |
              |  Process A   |             z l            |
              |              |             v e            |
               \            /              o \            /
                \  port P  /  RECEIVE ---> u  \          /
                 \________/   MESSAGE      s   \________/

                                to site L
                                containing P, Q, & K


   A RECEIVE message is sent from site K to site L and is entered in the
   rendezvous table at site L.  At some other time, process B executes a
   SEND to port P from port Q specifying site L as the rendezvous site.


                    SITE K                         SITE L
                  ________                 R    ________
                 /        \                e   /        \
                /          \               n T/          \
               /            \              d a            \
              |              |             e b  Process B |
              |  Process A   |             z l            |
              |              |             v e            |
               \            /              o \            /
                \  port P  /               u <--- port Q /
                 \________/    SEND        s   \________/
                                to site L
                                containing P & Q


   A rendezvous is made, the rendezvous table entry is cleared, and the
   transmission to port P at site K takes place.  The SEND site number
   (and conceivably the SEND port number) are appended to the messages
   of the transmission for the edification of the receiving process.











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


                SITE K                                SITE L
              ________                              ________
             /        \                            /        \
            /          \                          /          \
           /            \                        /            \
          |   Process A  |                      |  Process B   |
          |              |                      |              |
          |              |                      |              |
           \  port P    /                        \  port Q    /
            \          / <---- transmission <---- \          /
             \________/    to port T, site K       \________/
                            containing data and L

   Process B may simultaneously wish to execute a RECEIVE from port N at
   port M.

   Note that there is only one important control message in this system
   which moves between sites, the type of message that is called a
   Host/Host protocol message in [3].  This control message is the
   RECEIVE message.  There are two other possible intersite control
   messages: an error message to the originating site when a RECEIVE or
   SEND is timed out, and the SEND message in the rare case when the
   rendezvous site is not the SEND site.

   Of course there must also be a standard format for messages between
   ports.  For example, the following:

























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