rfc62.txt

RFC技术文档 从0000－05

RFC 62                  IPC for Resource Sharing          3 August 1970


   directly connected to the IMP.  The IMPs themselves are connected
   together by 50-kilobit phone lines (much higher rate lines are a
   potential), although each IMP is connected to only one to five other
   IMPs.  The IMPs provide a communications subnet through which the
   Hosts communicate.  Data is sent through the communications subnet in
   messages of arbitrary size (currently about 8000 bits) called network
   messages.  When a network message is received by the IMP at the
   destination site, that IMP sends an acknowledgment, called a RFNM, to
   the source site.

   A system for interprocess communication for the ARPA Network (let us
   call this IPC for ARPA) is currently being designed by the Network
   Working Group, under the chairmanship of S. Crocker of UCLA.  Their
   design is somewhat constrained by the communications subnet [5]<9>.
   I would like to compare point-by-point IPC for ARPA with the one
   developed in this paper; however, such a comparison would first
   require description here, almost from scratch, of the current state
   of IPC for ARPA since very little up-to-date information about IPC
   for ARPA appears in the open literature [2].  Also, IPC for ARPA is
   quite complex and the working documents describing it now run to many
   hundred pages, making any description lengthy and inappropriate for
   this paper.<10> Therefore, I shall make only a few scattered
   comparisons of the two systems, the first of which are implicit in
   this paragraph.

   The interprocess communication system being developed for the ARPA
   Network comes in several almost distinct pieces: The Host/IMP
   protocol, IMP/IMP protocol, and the Host/Host protocol.  The IMPs
   have sole responsibility for correctly transmitting bits from one
   site to another.  The Hosts have sole responsibility for making
   interprocess connections.  Both the Host and IMP are concerned and
   take a little responsibility for flow control and message sequencing.
   Applications of the interprocess communication system described in
   this paper leads me to make a different allocation of responsibility.
   The IMP still continues to move bits from on site to another
   correctly but the Network Controller also resides in the IMP, and
   flow control is completely in the hands of the processes running in
   the Hosts, although using the mechanisms provided by the IMPs.

   The IMPs provide the SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY, and
   UNIQUE operations in slightly altered forms for the Hosts and also
   maintain the rendezvous tables, including moving of SEND ports when
   necessary.  Putting these operations in the IMP requires the
   Host/Host protocol program to be written only once, rather than many
   times as is currently being done in the ARPA Network.  It is perhaps
   useful to step through the five operations again.

   SEND.  The Host gives the IMP a SEND port number, a RECEIVE port



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


   number, the rendezvous site, and a buffer specification (e.g., start
   and end, or beginning and length).  The SEND is sent to the
   rendezvous site IMP, normally the local IMP.  When a matching RECEIVE
   arrives at the local IMP, the Host is notified of the RECEIVE port of
   the just arrived message.  This port number is sufficient to identify
   the SENDing process, although a given operating system may have to
   keep internal tables mapping this port number into a useful internal
   process identifier.  Simultaneously, the IMP begins to ask the Host
   for specific pieces of the SEND buffer, sending these pieces as
   network messages to the destination site.  If a RFNM is not received
   for too long, implying a network message has been lost in the
   network, the Host is asked for the same data again and it is
   retransmitted.<11> Except for the last piece of a buffer, the IMP
   requests pieces from the Host which are common multiplies of the word
   size of the source Host, IMP, and destination Host.  This avoids
   mid-transmission word alignment problems.

   RECEIVE.  The Host gives the IMP a SEND port, a RECEIVE port, a
   rendezvous site, and a buffer description.  The RECEIVE message is
   sent to the rendezvous site.  As the network messages making up a
   transmission arrive for the RECEIVE port, they are passed to the Host
   along with RECEIVE port number (and perhaps the SEND port number),
   and an indication to the Host where to put this data in its input
   buffer.  When the last network message of the SEND buffer is passed
   into the Host, it is marked accordingly and the Host can then detect
   this.  (It is conceivable that the RECEIVE message could also
   allocate a piece of network bandwidth while making its network
   traverse to the rendezvous site.)

   RECEIVE ANY.  The Host gives the IMP a RECEIVE port and a buffer
   descriptor.  This works the same as RECEIVE but assumes the local
   site to be the rendezvous site.

   SEND FROM ANY.  The Host gives the IMP RECEIVE and SEND ports, the
   destination site, and a buffer descriptor.  The IMP requests and
   transmits the buffer as fast as possible.  A SEND FROM ANY for a
   non-existent port is discarded at the destination site.

   In the ARPA Network, the Hosts are required by the IMPs to physically
   break their transmissions into network messages, and successive
   messages of a single transmission must be delayed until the RFNM is
   received for the previous message.  In the system described here,
   since RFNMs are tied to the transmission of a particular piece of
   buffer and since the Hosts allow the IMPs to reassemble buffers in
   the Hosts by the IMP telling the Host where to put each buffer piece
   then pieces of a single buffer can be transmitted in parallel network
   messages and several RFNMs can be outstanding simultaneously.  This
   enables The Hosts to deal with transmissions of more natural sizes



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


   and higher bandwidth for a single transmission.

   For additional efficiency, the IMP might know the approximate time it
   takes for a RECEIVE to get to a particular other site and warn the
   Host to wake up a process shortly before the arrival of a message for
   that process is imminent.


   5. Conclusion

   Since the system described in this paper has not been implemented, I
   have no clearly demonstrable conclusions nor any performance reports.
   Instead, I conclude with four openly subjective claims.

   1) The interprocess communication system described in Section 2 is
   simpler and more general than most existing systems of equivalent
   power and is more powerful than most intra time-sharing system
   communication systems currently available.

   2) Time-sharing systems structured like the model in Section 2 should
   be studied by designers of time-sharing systems who may see a
   computer network in their future, as structure seems to enable
   joining a computer network with a minimum of difficulty.

   3) As computer networks become more common, remote interprocess
   communication systems like the one described in Section 3 should be
   studied.  The system currently being developed for ARPA is a step in
   the wrong direction, being addressed, in my opinion, more to
   communication between monitors than to communication between
   processes and consequently subverting convenient resource sharing.

   4) The application of the system as described in Section 4 is much
   simpler to implement and more powerful than the system currently
   being constructed for the ARPA Network, and I suggest that
   implementation of my method be seriously considered for adoption by
   the ARPA Network.


 <Footnotes>

    1. Almost any of the common definitions of a process would suit the
       needs of this paper.

    2. Or perhaps there is only one permanently known port, which
       belongs to a directory-process that keeps a table of
       permanent-process/well-know-port associations.

    3. That program which prints file directories, tells who is on other



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


       teletypes, runs subsystems, etc.

    4. 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.

    5. I use operating system rather than time-sharing system in this
       section to point up the fact that the autonomous systems at the
       network nodes may be either full blown time-sharing systems in
       their own right, and individual process in a larger
       geographically distributed time-sharing system, or merely
       autonomous sites wishing to communicate.

    6. For a SEND FROM ANY message, the rendezvous site is the
       destination site.

    7. For readers familiar with the once-proposed re-connection scheme
       for the ARPA Network, the above system is simple, comparatively,
       because there are no permanent connections to break and move;
       that is, connections only exist fleetingly in the system
       described here and can therefore be remade between any pair of
       processes which at any time happen to know each other's port
       numbers and have some clue where they each are.

    8. Crowther says this is not the virtual net concept.

    9. As one of the builders of the ARPA communications subnet, I am
       partially responsible for these constraints.

   10. The reader having access to the ARPA working documents may want
       to read Specifications for the Interconnection of a Host to
       an IMP, BBN Report No. 1822; and ARPA Network Working Group
       Notes #36, 37, 38, 39, 42, 44, 46, 47, 48, 49, 50, 54, 55, 56,
       57, 58, 59, 60.

   11. This also allows messages to be completely thrown away by the IMP
       subnet it that should ever be useful.


 [REFERENCES]

    1.  Ackerman, W., and Plummer, W.  An implementation of a
            multi-processing computer system.  Proc. ACM Symp. on
            Operating System Principles, Gatlinsburg, Tenn.,



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


            Oct. 1-4, 1967.

    2.  Carr, C. Crocker, S., and Cerf, V.  Host/Host communication
            protocol in the ARPA network.  Proc. AFIPS 1970 Spring
            Joint Comput. Conf., Vol. 36, AFIPS Press, Montvale, N.J.,
            pp. 589-597.

    3.  Dennis, J., and VanHorn, E.  Programming semantics for
            multiprogrammed computations.  Comm. ACM 9, 3 (March,
            1966), 143-155.

    4.  Hansen, P.B.  The nucleus of a multiprogramming system.  Comm.
            ACM 13, 4 (April, 1970), 238-241, 250.

    5.  Heart, F., Kahn, R., Ornstein, S., Crowther, W., and Walden, D.
            The interface message processor for the ARPA computer
            network.  Proc. AFIPS 1970 Spring Joint Comput. Conf., Vol.
            36, AFIPS Press, Montvale, N.J., pp. 551-567.

    6.  Lampson, B.  SDS 940 Lectures, circulated informally.

    7.  _______.  An overview of the CAL time-sharing system.  Computer
            Center, University of California, Berkeley, Calif.

    8.  _______.  Dynamic protection structures.  Proc.  AFIPS 1969 Fall
            Joint Comput. Conf., Vol. 35, AFIPS Press, Montvale, N.J.,
            pp. 27-38.

    9.  Roberts, L., and Wessler, B.  Computer network development to
            achive resource sharing.  Proc.  AFIPS 1970 Spring Joint
            Comput. Conf., Vol. 36, AFIPS Press, Monvale, N.J., pp.
            543-549.

   10.  Spier, M., and Organick, E.  The MULTICS interprocess
            communication facility.  Proc. ACM Second Symp. on Operating
            Systems Principles, Princeton University, Oct. 20-22, 1969.



Author's Address

   D. C. Walden
   Bolt Bernakek and Newman, Inc.
   Cambridge, Massachusetts


        [ This RFC was put into machine readable form for entry ]
        [ into the online RFC archives by Adam Costello 3/97 ]


Walden                                                        [Page 20]